Download the PHP package remp/campaign-module without Composer

Campaign

Campaign admin allows you to create banner campaigns without knowledge of HTML/CSS/JS, A/B test the banners and in combination with REMP Beam (for providing statistics) display and evaluate performance of your campaigns.

Integration with CMS/CRM

Javascript snippet

Include following snippet into the page to process campaigns and display banners. Update rempConfig object as needed.

Note: To automatically track banner events to BEAM Tracker, add also tracker property to rempConfig object. See BEAM README for details. The two snippets complement each other and can be combined into one big JS snippet including Campaign and Beam functionality.

Single-page applications

If you use single-page application and need to reinitialize JS library after it's been loaded:

1. Update the rempConfig variable to reflect the navigation changes.
2. Call remplib.campaign.init(rempConfig) again to reinitialize the JS tracking state. All existing banners will hide and campaigns will be evaluated again.

Segment integration

To determine who to display a campaign to, Campaign is dependent on user segments - effectively lists of user/browser IDs which should see a banner. You can register as many segment providers as you want, the only condition is that the providers should work with the same user-base (one user ID has to always point to the) same user.

The implementation is required to implement App\Contracts\SegmentContract interface.

All registered implementations are hidden behind facade of SegmentAggregator. This facade is then used to display available segments in configuration listings and to evaluate actual members of segments during campaign runtime.

If you want to link the Campaign to your own system, these are the methods to implement:

• provider(): string: Uniquely identifies segment provider among other segment providers. This is internally required to namespace segment names in case of same segment name being used in multiple segment sources.

• list(): Collection: Returns collection of all segments available for this provider. The structure of response is:

• users(CampaignSegment $segment): Collection: Returns list of user IDs belonging to the segment.

  • $segment: Instance of CampaignSegment holding the reference to segment used in a campaign.

  The response is than expected to be collection of integers/strings representing user IDs:

• checkUser(CampaignSegment $campaignSegment, string $userId): bool: Checks whether given userId belongs to the provided campaignSegment. This can either be done against external API (if it's prepared for realtime usage) or against cached list of user IDs - it's internal to the implementation. If the implementation doesn't support user-based segments, return false.

• checkBrowser(CampaignSegment $campaignSegment, string $browserId): bool: Checks whether given browserId belongs to the provided campaignSegment. This can either be done against external API (if it's prepared for realtime usage) or against cached list of browser IDs - it's internal to the implementation. If the implementation doesn't support browser-based segments, return false.

• cacheEnabled(): bool: Flag whether the segments of this provider used in active campaigns should be cached by the application or not. If true, Campaign will every hour request users() for each active Campaign and stores the collection of user IDs to the application cache.

• getProviderData(): Provider can pass arbitrary data back to the user's browser. This can be leveraged to cache browser/user related information without affecting the backend system. This data can be then altered by JS in the frontend application (if needed). All provided data is passed back to the server on each campaign/showtime request - on each banner display attempt.

  Note: We use this kind of caching to count number of trackable events directly in browser. Segment rules based on these events are then evaluated based on the data provided in cache instead of hitting database. This method dramatically improved performance of REMP Beam event database (Elasticsearch).

• setProviderData($providerData): void: Complementary providerData method to store back the data provided by frontend application in incoming request.

When implemented, create a segment provider providing the instance of your implementation. The provider should set \App\Contracts\SegmentAggregator::TAG to the class so your implementation would get also registered to the SegmentAggregator.

Banner custom styles

Banners use default system fonts. If you want to use your own fonts you can add styles for .remp-banner .serif and .remp-banner .sans-serif to custom css field, or directly to web page using campaign showtime functionality.

Example:

Settings and features

Campaign position collision resolving (experimental)

By default, Campaign displays all active and matched banners to the positions they're intended to be displayed at. If you want to ensure that there's always only one banner displayed at a single position, you can enable this feature with ENV variable:

When this feature is enabled and the system resolves multiple banners at the same position, the rules are:

• Display the banner which is part of the campaign with the most variants.
• If there are more of them, display the banner with the most recently updated campaign.

Collapsible banner state storing

Collapsible banner stores its collapse state and displays in the same state on the next display (expanded, collapsed). If user collapses campaign banner then it displays collapsed on the next display and vice versa.

In collapsible banner settings there is a toggle to override this behaviour and display banner always in initial state.

Snippets

Campaign supports use of snippets in your banner template contents, custom javascript and custom css. You can create snippets using Add new snippet in the Snippets main menu section.

You can use created snippets by adding {{ snippet_name }} to one of the fields used in banner content or in custom javascript & css.

Campaign Debugger

To be able to debug live campaigns and troubleshoot problems, Campaign provides Campaign Debugger tool.

Set CAMPAIGN_DEBUG_KEY in Campaign .env file. It can be any (preferrably random) value - you will be asked for the key later, when working with debugger.

To start debugger, go to page that displays campaign(s) you want to debug and append #campaignDebug to the URL. In the debugger window, fill in required parameters Debug key and Campaign public ID and submit. After page reload, debugger should provide you with a reason why the particular campaign was shown/not shown.

API Documentation

Campaign provides a simple API for several tasks described bellow.

All examples use http://campaign.remp.press as a base domain. Please change the host to the one you use before executing the examples.

All examples use XXX as a default value for authorization token, please replace it with the real token API token that can be acquired in the REMP SSO.

All requests should contain (and be compliant) with the follow HTTP headers.

API responses can contain following HTTP codes:

If possible, the response includes application/json encoded payload with message explaining the error further.

POST /api/banners/BANNER_ID/one-time-display

Campaign supports one-time display of banners to specific users. Such banner does not need associated campaign to be displayed. This can be used e.g. as a way of reminding users about required actions (instead of notifying them via email).

When calling this endpoint, please replace BANNER_ID in URL with an actual ID of the banner. Each one-time banner has to specify its expiration date and a user it shows to (targeted either via user ID or via browser ID).

Body:

Examples:

Response:

Valid response with 202 HTTP code:

Override user's presence in segment's cache

• Add user: POST /api/segment-cache/provider/{segment_provider}/code/{segment_code}/add-user
• Remove user: POST /api/segment-cache/provider/{segment_provider}/code/{segment_code}/remove-user

If segment provider supports it, Campaign will cache members of segment for faster access. If segment is dynamic (changed often), it can lead to incorrect campaign targeting (old data).

Note: Interval for cache invalidation is set to one hour (check App\Console\Kernel->schedule()).

These two API endpoints allow overriding membership of one user in cached segment from outside of Campaign (eg. from CRM).

Both endpoints return response 404 Not found if segment is not actively used by active or scheduled campaign.

API path parameters:

Body:

Examples:

Response:

Valid response with 202 HTTP code:

Response with 404 HTTP code:

Newsletter Banner

This banner type allows you to directly collect newsletter subscribers.

In most cases you are going to need your own API proxy, since most newsletter APIs (including REMP CRM) make use of private tokens that should not be exposed to client. In case your newsletter API does not require such, you might not need a proxy.

Setup

All configuration options are set via .env, refer to .env.example for full list of available options.

API requirements

Newsletter API is required to respond with proper HTTP response code. On both success and failure, there is and custom event emitted. See next section for details.

Custom Events

Custom events rempNewsletterSubscribeFailure or rempNewsletterSubscribeSuccess are available if requests are configured with XHR. Events are fired on form element. Event contains following items in detail prop:

Error handling example

Healthcheck

Route http://campaign.remp.press/health provides health check for database, Redis, storage and logging.

Returns:

• 200 OK and JSON with list of services (with status "OK").
• 500 Internal Server Error and JSON with description of problem. E.g.:

MaxMind - GeoIP2 Lite

This product includes GeoLite2 data created by MaxMind, available from http://www.maxmind.com. Due to the licence changes, you need to update the database manually. If you do, provide path to the updated database via MAXMIND_DATABASE environment variable.

RTM tracking

Following params are added to every request or link within banners. They serve for campaign performance tracking.

• rtm_source: "remp_campaign" => always same string
• rtm_medium: displayType => overlay or inline
• rtm_campaign: campaignUuid => campaign id
• rtm_content: uuid => banner id
• banner_variant: variantUuid => banner variant id (in campaign)