Download the PHP package symbiote/silverstripe-local-personalisation without Composer

Local Profiles

Overview

Builds a profile of a visitor, "tagging" behaviour based on the pages visited, actions performed, location, or device characteristics. Preserves privacy since the profile is stored in the browser only, without relying on server data or logged-in user information.

This module enables marketers and developers to collaborate effectively, by providing both a CMS user interface and an API.

CMS users can define "rule sets" to group one or more "rules". Each rule determines when and how behaviour should be tagged. For example, "if URL contains 'marketing', then add 'interested-in-marketing' tag".

These tags can then be used for matching rules against objects managed in the CMS (such as pages or content blocks), and show/hide them based on in-browser decisions. Alternatively, you can control this behaviour programmatically, enabling sophisticated rule definitions that wouldn't be feasible in a CMS UI.

Because all decision making happens in the browser, you can still serve cached responses with all variations delivered to the browser, but only some variations shown to the visitor.

Example use cases:

• Show location-specific announcements on the homepage
• List featured products from the closest store (via browser geolocation)
• Show topic-specific content blocks based on the pages the visitor has previously viewed
• Show promotions for a specific marketing campaign, based on traffic coming in with a campaign URL parameter
• Hide welcome message if the visitor has seen it before
• Show "Contact helpdesk?" call-to-action if visitors view a FAQ entry for longer than 30 seconds

Limitations:

• All variations are visible to all visitors (for example, this can't be used for targeted promo codes)
• All decision making is visible in the browser (including any built-in bias and dodgy marketing tactics)

  Installation

Composer

Javascript and CSS

Add the required frontend logic into your main template:

Alternatively, check app/webpack.config.js on how to compile the requirements into your own frontend bundle.

Metadata

Personalisation rules are loaded as JavaScript metadata.

By loading this as a separate route, you avoid inline scripts and make it easier to secure your website with a Content Security Policy. It also helps with caching: Personalisation rules apply immediately on save, even when the page output might be cached (via HTTP caching or static publishing).

Apply the extension

In order for the frontend logic to be triggered, you generally want to apply an extension to at least one content object. This adds a new "Personalisation" tab in the CMS.

Apply on pages:

Apply on content blocks:

Modify templates

Now add some metadata to the markup for the content object you're rendering: $p13nClasses to your class attribute, and $p13nAttributes to the element.

Example for the content blocks holder template (store in themes/mytheme/templates/DNADesign/Elemental/Layout/ElementHolder.ss):

Test Operation

You should be ready to define rules now. Check for Profile.js console messages in your browser to ensure everything is set up correctly.

Developer Usage

Rules for profile segmentation

Rules are defined in the CMS

They can be triggered for;

• A regex match against content

Manually applying rules

By applying the PersonalisationExtension to a content object, you can use $p13nClasses and $p13nAttributes in your templates.

Alternatively, you can build the required markers from scratch:

• add the lp-item css class
• Add the data-lp-tags attribute to list (comma separated) the tags applied on the profile to trigger this element
• Add the data-lp-type attribute to indicate whether to "show" (default) or "hide" the element
• Add the data-lp-times attribute (optional) to indicate how many times the user's profile has to have been tagged
• Add the data-lp-timeframe attribute to indicate what timeframe (ie -1 week) the tagging must have happened

Events

The following events are triggered and can be responded to in custom code

• local_profile_match_tag
• local_profile_apply_rule
• local_profile_add_tag

Bind to these as document.addEventListener('local_profile_add_tag', function (eventData) {})

Local Development

Build

The frontend assets are stored in app/. You can use yarn to install dependencies and kick off a build:

Javascript, HTTPS and hot reloading

To fully test the functionality locally, you'll need to run your webserver on HTTPS which is required for geolocation in most browsers now.

When developing the Javascript code for the module, it can be helpful to get source maps (breakpoints!) and hot reloading. The module already has a yarn devserver command. You'll need to extend the webpack.config.js to work around CORS issues when including it in your page (see webpack devserver docs).

Now you can use the dev server (usually on port 4200) with the preferred hostname for your Silverstripe website:

Caution: In order to use geolocation without HTTPS in Chrome, you need to allow insecure origins.