Q&A

 

What is Site?

Site is a website personalization tool which is part of the Marigold Engage platform.
It allows you to personalize your website based on visitor behavior data, and for identified visitors personalization can be based upon any (1:1) data available in Marigold Engage.

 

Why should I use it?

Site can be used as a website personalization tool and a website data gathering tool.
It allows you to gather website visitor behavior data.
It allows you to personalize the website based upon gathered website behavior data.
It allows you to easily create personalized content inside Marigold Engage which can be served to your website visitors (easy for the marketer).
It allows you to use gathered website data for email, push and sms communication towards your identified visitors.

 

How is it commonly used?

It is commonly used to show 'ad hoc' website offer banners e.g. Black Friday.
It is commonly used to offer a subscribe pop-in for unidentified visitors in order to identify them and store these profiles directly inside Marigold Engage.
It is commonly used to trigger abandoned cart data towards Marigold Engage which then can be handled in a smart abandoned cart journey.
It is commonly used to host product/article recommendations content blocks directly on the website since it is seamlessly integrated with Recommendations.
It is commonly used to extract aggregated website visitor data towards your Marigold Engage contact base in order to personalize omnichannel communications.

 

What do I need to do to identify my website visitors as CRM identified visitors?

The identification is based on a parameter (M_BT) added to the email through which the visitor enters the website. This parameter is only added if the Site tracker is activated on the customer environment. This activation is done by a member of the Marigold service team. Please contact Marigold.

Next, the tracker must be defined in the configuration of the Engage environment.

 

How can I create Site reporting segments including data from my Engage environment?

Site reporting segments can use Site profile data, tag information and also CRM data. CRM data refers to Engage information. To be able to access these Engage fields in Site, it is required to

  1. Create  a Site Service account, tick the option ‘Connect to Engage’ for the universe and enter credentials to connect.
  2. Select the Audience from where data must be retrieved.
  3. Select the fields in the selected Audience that must be made available for the segment definition

 

How can I use Engage information in offers?
  1. Engage fields can be used to define the Audience for an Offer. The fields are available for selection in the Constraint editor.  (The same condition applies as when using Engage fields for Site segments. See previous question)
  2. For Offer actions of type HTML or popup/popin a Engage 'targeting' Journey can be selected, together with an Input component. In this case the Journey must be configured as a targeting Journey, the Input component must be configured and a page must be designed.
  3. In Offer activities and conversion a CRM page tag can be selected.

    The Site tracking script must be on the Engage page.

    Example: Typically this would be a Engage page that is used in the website, with a content renderer. The tracking script is used in the content renderer itself. E.g. a click on a banner takes the visitor to the registration page, but the content of this page comes from Engage.

  4. For Offer follow-up and retargeting, a Engage retargeting Journey can be selected.

 

How can I use my Site information in Engage?

Information from Site can be exported to Engage, and created as a profile extension to an Audience List. To do this

  1. Create a service account.
  2. Check ‘Connect to Engage’ for the universe and enter credentials.
  3. Select the Audience in Engage for which a profile extension must be created
  4. Configure the Export in Site and define what fields need to be exported from the profile data, tag values or segments.

 

How can I use Site profile data, tag information or data from my Engage environment on my website, to use in my custom JavaScript?

With offers there is little reason to add custom JavaScript to change page elements based on the Site data. You already do this with offers in a profound way. But it might be useful, for instance, if you work with a third-party bannering agency that uses specific JavaScript to show a certain overlay.

 

If the name of the tag changes, does this mean that all values are lost?

Every tag has an underlying ID which is used to identify the tag. When the name or public name of a tag changes, the values are not lost. However, if you change the public name, your JavaScript tracking call must also be changed to use the new public name. If values enter through the old public name, these will no longer be stored. So in short, history is kept but no longer updated.

 

If I use offers, does Site change the structure of my website?

No, everything happens front-side with JavaScript. The visitor who gets an offer sees the changes because Site adds or changes content for him front-side with JavaScript. No changes to the back-end structure of the websites are done.

If, in an image placement you were to replace an image with another image, the entire image tag is replaced front-side. So if the image tag has a class or styling (for instance for responsive design), you need to apply it also to the placement. Including the image’s WIDTH and HEIGHT attributes. The image’s ALT attribute is defined in the offer action.

 

Can I use completely different domains in one universe?

You can use as many different domains and subdomains as you like. You just have to put the same script on all the pages of the different domains and behavior will be tracked over all the websites.

 

Is it possible to send a notification to an external system with the information of which offers have been presented to each user?

Information can be exported from Site with such data on ALL contacts or a certain segment. Export is possible to an external FTP from where the external system can pick this up. It can also be done in real-time on the website with custom Javascript and the Site API for 1 particular contact at a time and for the trigger at that moment. (being in/out an offer)

 

Within an action, is it possible to select different images based on added segmentation? For example, we want to create an offer for very engaged visitors but show a different image if it is a male or female?

This is possible in the personalization of the offer. The text or image name can be personalized with any profile attribute, such as gender for identified visitors. The image name would be something like http://image_url/~GENDER~.jpg. You only must make sure that these image names exist in the folder or storage location.

 

Is there any approval workflow?

Not planned

 

Can we export the reporting?

There is no visual option to export reports. However a manual selection of records and paste in excel or other software is possible.

 

Is there a direct access to data stored in the Site tables and possibility to export these?

This is not possible in Site.

 

Can a user select manually a period on a graph?

You can drag on the graph and select this way a detailed period in the graph. This is possible on all graphs.

 

Do we have AB-test possibilities?

AB is standard provided in Site. The winner can be selected manually or automatically.

  • Automatically—  The winner is based on the most conversions or the number of clicks on the item. The winner is chosen automatically if there is a statistically significant difference* between the items (currently set at 5%).
  • Manually — Select the option 'Choose winner manually' from the drop-down list. After running the offer, a second field is displayed allowing you to select the winning version manually.

 

Can we have multiple lists in one universe?

1. One universe - one table
Most simple and recommended approach. You can easily define offers and/or placements for all websites or only for one. So that way, you can have different offers per country. If needed, you could also create different tags per website and have a tag 'Country' to see which country they visit most.
The only disadvantage you might have for this approach is that the global behavior (like time spent, device used, etc.) is combined over all the websites. Sometimes customers want to see that split, sometimes not.

2. Multiple universes - one table
Not recommended. No easy way to copy-paste from one universe to another, more complex setup. No global Site profile. However this approach will split global behavior per universe, and will create 1 extended profile per universe on the Engage user. 

3. One universe - multiple tables
Not recommended. If one device can be linked to multiple Engage users from different lists, you will potentially get profile conflicts: Site doesn't know from which list to take the CRM data if the custom identifier is the same (only the fields that exist on each list will be available), the export will only export the profile that is updated as last to the correct list, there is a risk that behavior from one user ends up in the profile of another (only upon identification the profile switches). If users exist on multiple lists: there will be conflicts. If a user can only exist in one list, that is more safe - but in that case, why split up the lists? 

 

What happens when we change the main audience list in the universe? What impact does it have?

As a result, each Engage contact will get a different ID and the key is LISTID+USERID

Custom identification or not:

    • No custom identification : the previously known profile is no longer used and a new profile is created
    • Custom identification is used.
      • If the contact was already identified, his previously known profile will not be used but a new profile is created and thanks to this custom identifier the profiles will be merged after the matching in Engage has been done
      • If the contact was not yet custom identified, a new profile is created but cannot be merged with the old as there is no custom identifier yet to match

If a previously known profile visits the website again and still has his old Engage ID (no new authentication with his new id), he will keep his historic profile. At the time he will authenticate with his new id:

  • For profiles that are only third party identified CRM data will be lost since the third party id will not be known on the new list
  • For profiles that are custom identified, CRM data can be retrieved from the new list based on the custom identifier                              

If you have active offers thatdon’t use CRM fields, the audience will not be affected.

If you have active offers thatdo use CRM fields and the CRM fields  exist on the new list, the audience evaluation will keep working. But it might be that a profile (temporarily) loses its CRM data until their next visit on the website.

For constraints built in Site with CRM fields: you should be careful that all the fields still exist in the new lists – or update the constraints after you changed the list in the universe. If constraints have been built with fields that no longer exist, the constraint evaluation will always fail.

For reports, there is impact on the identification report and the number of identified profiles. Again this depends on the type of identification that has been configured. Might be that the number of (identified) profiles goes up but after merging the profiles (and dropping non quality profiles) it will drop again to the correct level.

For exports to Engage, as soon as you change the list in the universe, from the next day, the new list will get the new profile extensions. The old profile extensions on the previous list will remain and not be updated anymore. The new profile extensions will only get filled for contacts that have authenticated on the new list, so it will take some time to collect the profiles again.

 

How long is data stored within Site?

Site currently holds data for 90 days. This means that if the contact does not return within 90 days, that the entire profile is removed from the Reporting database in Site.

On the Google cloud the history is currently kept for ever. This includes First visit, last visit, averages, aggregated data (calculated on the last 90 days), tagvalue data when not decayed over time.

This means that if a contact comes back after these 90 days, and Site is able to identify this contact, we can retrieve his complete profile from the Google cloud.

Additional note: the profiles that have been removed from the Site Reporting database after 90 days inactivity, will no longer be part of the export to Engage; If the export is set as 'merge', the Engage profile will remain. If the export is set to replace the data, then the Engage profile will disappear as it is no longer a quality profile!

 

What synchronisation processes exist and what is their frequency?

There are several synchronisation processes running on different levels within Site. Following is an overview:

  • Offers: offers created in Site are synced  the moment they are picked up by the sync thread. Once synced, it takes until the start of the next minute before they are shown. In general we can state that the maximum waiting time is around 3 minutes.
  • Exports run once a day. For daily exports this implies that they are run just after report calculation. Depending on the amount of data in the universe, this export might happen at different moments.
  • Live reporting is continuously refreshed, however it is always a couple minutes behind as the data must be transferred from front to back end. There is a maximum of 5 to 10 minutes of delay.
  • Visitor insight reports: once a day, during the night. Not all universes are calculated at the same time. The first might start at 1 am and the last one at 5am for instance, depending on the capacity and the number of universes as well as the load.
  • Other reporting is calculated once a day: tag reporting, offer reporting, Segment reporting. These reports are calculated during the night.
  • Exposure of Site fields to API: These fields are available in the API the moment they are available on the profile.  This implies also that these fields are loaded asynchronously. When a profile identifies itself, it can take some time before these fields are visible, depending on the asynchronous  process.
  • Exposure of Engage fields to Site: The frequency of synchronization is configurable in the administration tool by Marigold employees. Standard synchronization is set to once a day. The exact moment of sync is not fixed but could be configured if required. The last synchronization time is indicated on the Site dashboard in the info panel.

 

How is a visit defined in Site?

A visit in Site is a period of time in which the contact is active. Whenever the contact hits your website, a tracking call will be fired to Site on which the profile will be updated. When hitting an existing profile, Site will check the difference between the current time and the time of the previous hit on the profile. If the difference (in minutes) between these 2 times is more than the configured threshold, Site will consider the tracking call as a new visit.

Some example scenario's to clarify it a bit more:

Scenario 1: Returning contacts

The threshold is set to 30min.
A contact opens your website within a browser.
The contact clicks around a few times hitting a certain profile
10 minutes later, the contact returns to your website in the same browser
Within this scenario, NO NEW VISIT is generated since the time between the 2 sessions was less than 30 minutes

Scenario 2: Multi-device contacts

A known/identified contact opens your website within a browser.
The contact clicks around a few times hitting a certain profile.
At the same time, the contact opens your website on his mobile (as an identified visitor).

Within this scenario, NO NEW VISIT is generated since the same profile is hit from the 2 devices and the time between the 2 sessions was less than 30 minutes.

The following scenario's DO GENERATE A NEW VISIT:

  • An anonymous contact returning after more than 30 minutes
  • An anonymous contact browsing on different devices or browsers (this will generate different profiles and hence different visits)
  • An identified contact using different devices with more than 30 minutes in between 2 sessions

Note that at the moment Site does not have an option to 'force' a new visit in any way. So when you want to test scenario's that need multiple visits for the same contact, you will actually have to wait till the 30 minutes are over.

 

The Site Inspector is not loaded although the Site base script is loaded on the website.

This could have 2 reasons :

  • The Inspector is hidden behind the menu or another element. You can crosscheck this with the console and 'inspect' in the top left corner of the website. Crosscheck the z-index.
  • The website is blocking it or having issues displaying it for multiple reasons

For the latter you can try to use the following script in the console when you have opened the URL from the Site - Offer settings links (this last part is mandatory):

Copy 
window.BT = null;
window.name = 'INSPECTOR_%FILL IN THE UNIVERSE ID HERE%';
var wa = document.createElement("script"),
    wa_s = document.getElementsByTagName("script")[0];
wa.src = "%FILL IN THE LINK FROM THE UNIVERSE BASE SCRIPT SETTINGS HERE%";
wa.type = "text/javascript";
wa_s.parentNode.insertBefore(wa, wa_s);

 

Why are none of my Site Offers showing on the website?

I have injected the Site base snippet which I have found in the Site universe settings and loaded this through Google Tag Manager on all pages of my website, but still none of my offers are showing.

The base snippet contains the following when you paste it from the Universe settings.

Copy 
wa.bt_queue.push({JSON_OBJECT});

This JSON_OBJECT needs to be adjusted with proper variables which Site needs. All the possible variables can be found in the API documentation, but 1 important variable needs to be added in order to 'see' offers.

This variable is isTargeting:"true"

So a simple JSON_OBJECT which will load offer actions is the following

{ "isTargeting": true}

When this is 'pushed' with the base Site snippet, your offer will be loaded.

 

Which tables are created when linking Site to Engage?

The integration between Site and Engage uses the following relevant tables:

BT_UNIVERSES — When a Site universe is linked to an Engage list, the universe will be registered in this table. This table will be used to fill the universe drop-downs whenever a Site configuration is done in Engage (e.g. creating a retargeting journey requires the universe to be selected in the journey properties).

The table contains the following fields:

  • UNIVERSEGUID —The unique identification code of the universe
  • UNIVERSENAME —The name of the universe as it will be shown in the user interface
  • UNIVERSESCRIPT —The universe script that will be automatically added to any journey page that requires a tracking call
  • ACTIVE — Flag indicating whether the integration with the universe is still active
  • FIELDS —The fields that need to be synchronized between Site and Engage
  • ENDPOINT — The tracking call endpoint that has to be used when doing direct calls to the tracking call engine

BT_DOMAINS — When a Site universe is linked to a Engage list, each time an email is sent out to this list, the parameter m_bt is added to the URLs in order to be able to identify the visitors on the website landing pages. The addition of this parameter is done by the Site tracker that is automatically activated when linking a universe. This table contains the domains that are defined on the universe and the tracker will only add the m_bt parameter on links going to one of these domains.

The table contains the following fields:

  • UNIVERSEGUID —The unique identification code of the universe
  • LISTID — The list that is linked to the universe
  • DOMAINS — The list of domains for which the m_bt parameter should be added

BT_ACTIONS — This table is used whenever a (re)targeting or abandon cart journey is created. The information in this table is required to be able to show a list of (re)targeting or abandon cart journeys in Site.

The table contains the following fields:

  • CAMPAIGNID — ID of the journey that needs to be triggered upon (re)targeting
  • ACTIONID — ID of the Input Component that is used to enter the journey
  • UNIVERSEID — ID of the universe to which this journey is connected
  • TYPE — Type of Site journey
    • 0: targeting
    • 1: retargeting
    • 3: cart abandonment
  • PARAMS — XML containing a list of parameters defined on the Input Component. Some default parameters will be provided automatically by Site (e.g. offerid, actionid, cartid, products, …) but if the user has added some custom parameters he will be able to specify the values for those parameters in Site.
  • URL — The anonymous optiextension URL of the Input Component

 

How is a quality profile defined?

A quality profile is a profile that is considered to be of good quality. The definition of good quality can be set by using the include and exclude criteria in the universe configuration.

The definition of a quality profile is (implicitly) used in several locations throughout the platform.

Reporting

Most of the reporting only includes data from quality profiles. This means that:

  • As long as a profile is not a quality profile, its data will not be part of the reporting.
  • If a profile is a quality profile but no longer visits the website, at a certain moment that profile will no longer be a quality profile. At that time, the profile is considered a 'lost' profile.

Exception: Live reporting includes the data of all profiles.

Constraints

While setting up audiences throughout the application, we can also use the quality profile definition as a constraint. This will ensure, that the audience is limited to quality profiles.

This can be for example used while setting up certain offers that only need to be shown to your quality profiles.

Exports and Forecast calculation

While exporting data or calculating audience forecasts, only quality profiles are considered.

 

How can I see if a specific contact has been shown a Site offer?

You can create a Site profile export to an (FTP) file that captures the profiles that have viewed the offer:

The file export will include both anonymous and identified profiles.

If the offer that you want to check is only targeting identified profiles in its WHO audience constraints, then you can actually just export to Engage directly, and then view the 1:N data list attached to the main Audience List (defined in the universe settings by the relation that you defined for the export). That linked Data List will have a USERID field connecting each record back to the contact in the main Audience List.

But if you want to check for anonymous profiles that viewed the offer also, then export to file instead to get both identified and anonymous profiles.

You'll have to define the FTPS server, login, password, folder, and port for the export in the WHERE section.

Once the export is fully configured, you can manually trigger the export on the overview page by pressing the Play button on the row for the export.

The output file format will have a row for each profile who has viewed the offer; the columns of each row will be the attributes you selected in the WHAT section of the export.

 

What is the impact of a change the integration between Site and Engage?

Once Site is integrated with Engage, it is no longer possible in the UI to change this integration because this would have impact on the existing identified profiles. Do we have an overview of what the impact would be and/or what needs to happen if a customer wants to make a change anyway?

Scenario 1: Change of CUSTOMID field within the same list without overlapping custom ids

An example of this is when the customers wants to switch from the email address (which is not advised to be used) to a hash of the email.

  • If a fully identified user visits after this change, the interaction will be added on a new profile which will be lost after re)identifying
  • If a third party identified user visits after the change, nothing will change
  • If a custom identified user visits after this change, nothing will change
  • If an anonymous profile visits after this change, nothing will change

Scenario 2: Change of CUSTOMID field within the same list with the same custom ids

This scenario will not cause issues since we only need to change the field name

Scenario 3: Change of CUSTOMID field within the same list with overlapping custom ids

Since there is overlap in the custom identifiers profiles will get mixed up. In order to avoid this, the only option is to do a full remapping of the custom identifiers

This scenario will require a migration and needs to be analyzed in more detail.

Scenario 4: Change of list while keeping the CUSTOMID field value unchanged

An example of this is when the customers want to switch the Audience List but the new list has a field that also contains the CUSTOMID field.

  • If a fully identified contact visits after this change, the profile will be updated with new identifiers
  • If an anonymous visitors clicks on an email after this change, after a few hits the new profile will be merged into the old one based on the CUSTOMID

 

How does tag scoring work and why do tag values disappear?

Within Site you can setup tags on which we can send values via a tracking call. These tags and their values can later be used within:

  • Reporting
  • Segmentation
  • Personalization
  • Exports

A tag value has certain properties:

  • First hit
  • Last hit
  • Score
  • Total score
  • ...

The fact that a tag value disappears is a direct result of the way tag scoring works. Let's explain with a simple example.

Assume we have the following setup:

  • An hierarchical tag X has been defined:
  • with a single hierarchy level
  • with a decay of 33% per day

When this tag would be hit the first time on 1/1/2021 12:00, the score would decay with a speed of 33% per day. As a result the value of the tag will eventually disappear.

A tag value will disappear once the score goes below the defined threshold of 0,1. After that it will look like the visitor has never hit this tag before.

When a tag is hit subsequently before the tag value score reaches the threshold, the score of the tag is incremented with the new value (default: +1)

For example, let's assume that the tag is hit a second time on 1/2/2021 20:00. At that moment, the score of the tag would have decreased to 0.556. The new hit will cause the tag value to become 1.556 and the decrease will start again from the moment of that last hit.

 

How to disable tracking call scripts?

We currently have no in app option to delete a tracking call export. Therefore it should be done manually via the database.

In order to delete the tracking call export you first need to retrieve the id of the export by executing the following queries:

Copy 
SELECT E.*
FROM UNIVERSES U
INNER JOIN EXPORTS E ON E.UNIVERSEID = U.ID
WHERE E.TYPE = 3
  AND U.NAME = <NAME_OF_YOUR_UNIVERSE>

Once you have the id of the export that needs to be removed, execute the following queries:

Copy 
DELETE FROM SEGMENTS
WHERE EXPORTID = <ID_OF_YOUR_EXPORT>
/* segment query needs to be executed first or the export query will have a foreign key exception */
DELETE FROM EXPORTS
WHERE ID = <ID_OF_YOUR_EXPORT>

Finally, we should flush the cache to make sure the deleted exports are removed from the processing engine.

 

Why is the search-terms tag not being populated?

Due to a change made by Google in 2011, it is no longer possible to fetch the search terms when the search is performed by a signed-in Google user. More details here: https://googleblog.blogspot.com/2011/10/making-search-more-secure.html

 

Why are HTML attributes stripped from my offer?

I'm building an HTML offer in Site using attributes such as flex-direction, flex, box-shadow, transition, border-radius, border-image but when I save the offer, Site automatically strips these attributes from the HTML, breaking the offer styling. Why is this happening?

Site has an HTML Sanitizer in place to only allow certain tags, schemes, properties and attributes for security reasons. The whitelist is configured based on the OWASP defaults. The list of allowed items is part of the settings in Site Admin, hence a Site Admin User can add CSS properties to this whitelist upon request and after approval.

An overview of the settings that impact Site's HTML Sanitizer and their current values, for both the EU and US environment:

  • SANITIZER_ALLOWED_ATTRIBUTES
  • id
  • class
  • style
  • role
  • viewbox
  • xmlns
  • d
  • fill
  • opacity
  • SANITIZER_ALLOWED_CSS_PROPERTIES
  • position
  • justify-content
  • align-items
  • flex-direction
  • flex
  • box-shadow
  • transition
  • border-radius
  • border-image
  • SANITIZER_ALLOWED_SCHEMES
  • /
  • SANITIZER_ALLOWED_TAGS
  • style
  • svg
  • path
  • video
  • picture
  • figure

 

Is a tag pushed to Site, when the tracking call value is empty?

The tag value is a key that indicates which tag of 'Category' is hit. If the visitor of the website doesn't provide a value for this tag, nothing will happen.

The last known pushed value for this tag will display the last valid tag value.

 

Can Site register an Offer conversion when not all activities are hit?

No, Site does not require the visitor to first hit all the activities configured. Activities are merely an optional step to capture the visitor's progress towards offer conversion. The advantage of using activities is the possibility to create a funnel report listing all the steps. This report gives insights on the number of profiles in each step and as a result you can track the progress of each visitor.

So, although it is not required, it is still possible to set up a conversion with activities that are functionally required to reach the conversion trigger.

 

Why doesn't my sub-domain show up in Site's DOMAIN system tag?

Site uses the URL property on the payload to determine the value of the DOMAIN tag. E.g. https://site.selligent.com/features/2022-C_release.

  • If the URL uses a known top-level domain (e.g. com), Site will trim down the URL value to the second-level domain (selligent.com) and use that for the DOMAIN tag.

  • If the top-level domain is not known (e.g. corp), the entire host name will be used for the DOMAIN tag. For example, if you replace com with corp in the above selligent.com use case, a visit to https://site.selligent.corp/features/2022-C_release would result in a DOMAIN tag value of site.selligent.corp.

 

After having changed the access rights for Site in Engage, the user is unable to see all universes.

A new user is created in Engage and all access rights to Site have been configured in Engage for the Site dedicated organizations. However, when logging in through SSO to Site, the user does not see the linked universes for these organizations?

The Site universe and Engage organization names must be identical for this to work. If these are not identical, the above issue might occur.

 

Adding a CRM exposed field to my universe generates an error. What could be wrong?

While creating an exposed field on the universe for one of the linked CRM fields, an issue occurred. When opening the Profile Field Selector and selecting a CRM field, the following warning appears. What am I doing wrong?

The error message might be related to a known issue in the Site application. This error happens if the following conditions are met:

  • There are multiple universes

  • At least one of the universes is not linked to Campaign or Engage

  • The universe that is selected in the top header bar is one of the universes that is not connected to Campaign or Engage

  • The universe that you are currently trying to edit does have an active integration with Campaign or Engage

The issue is caused by the fact that the Profile Field Selector is accessing the universe that is selected on top (instead of the universe that you are currently editing) and which has no integration defined.
As a workaround, you can simply switch the universe that is selected on top to the same universe that you are currently trying to edit. This should do the trick.

 

How does the global optout work for Site?

Applying GDPR, customers have the ability to send optout requests to Marigold Engage. how does this translate for the Site module?

 

When a customer sends an optout request for a certain contact, the OPTOUT field in the customers Data List will be set to value 20180525.

Forwarding the optout request directly to Site has the following disadvantages:

  • If the contact has not been identified on the website, no Site profile exists and hence the optout can not be stored.
  • If the contact profile is deleted after the optout is stored, a new profile will be created but the optout flag will be lost.

To avoid these issues, the implementation of Site has been integrated directly with the OPTOUT field of the Audience list in Engage or Campaign.

The integration is done in the following way:

  • When a universe is connected to Engage/Campaign, the OPTOUT field of the MASTER Audience List is by default synced (even if it is not selected in the universe configuration)
  • When a profile is identified on the website, the data retrieved from Engage/Campaign will contain the value of the OPTOUT field
  • If the value of the OPTOUT field corresponds to 20180525, the tracking call response will contain "doNotTrack": true and as a result the script on the website will set a cookie sbt_dnt.
  • On the next hit, our script will detect the sbt_dnt cookie and will not send out a tracking call anymore.

Note that, if not deleted, the cookie will be on the browser for 30 days after which the tracking calls will be re-enabled. If the profile is still opted out, the cookie will be set again for another month.

 

Why is the synchronization between Site and CRM data done only once a day?

Synchronization between Site and CRM data is by default set up once a day but this can be changed if needed. However following needs to be considered:

  • How many identified profiles does the universe have?
  • How many fields are synchronized between Campaign/Engage and Site (and how much data is in those fields)?
  • How often do identified users visit the website?

The above parameters should give an idea how the load on the system will be impacted when increasing the number of times the data is synced between Engage and Site.

Every newly identified profile will asynchronously fetch its data from the Campaign/Engage database. When this data is retrieved, 2 things happen:

  • The ID of the retrieved record is stored in a table (on the Campaign install) that contains the IDs of all records that have been retrieved by Site.
  • The retrieved record is stored in a table (on the Site environment) in order to avoid that this data needs to be retrieved from Campaign again.

Since we cache this data on the internal API, we need a way to update this data if changes happen on the records in Campaign. This process is what we call the CRM synchronization and by default it happens once every 24 hours.

Let's explain the impact of increasing the number:

Example 1 (A retail customer) :
Assumption:
Customer X has 10.000 identified profiles.
Customer X has configured 5 CRM fields in Site.
The average visit frequency of the identified profiles is once per 3 days.
Current situation:
Once per day, 10.000 records are synchronized that each contain 5 fields.
Given the identified profiles visit once per 3 days, on average 3.333 profiles will be updated asynchronously.
Upon nightly reporting, all 10.000 profiles will be updated.
What if we increase the sync frequency to 24 times per day?
Once per hour (24 times per day), 10.000 records are synchronized that each contain 5 fields.
Given identified profiles visit once per 3 days, on average 139 profiles (3.333 / 24) will be updated asynchronously.
Upon nightly reporting, all 10.000 profiles will be updated.
Conclusion:
In this case, we can clearly see that there is not a lot of extra load on the system. The only thing that actually increases is the number of times the records are retrieved from Campaign but since it is only 10.000 records with 5 fields each, that load should be negligible (assuming the fields don’t contain a huge amount of data)

Example 2 (A publisher) :
Assumption:
Customer Y has 1.000.000 identified profiles.
Customer Y has configured 25 CRM fields in Site.
The average visit frequency of the identified profiles is 3 times per day (morning, noon, evening to read articles).
Current situation:
Once per day, 1.000.000 records are synchronized that each contain 25 fields.
Given the identified profiles visit multiple times per day, all profiles will be updated asynchronously. This will lead to 1.000.000 calls to our internal api service.
Upon nightly reporting, only the profiles that have not visited since the last sync will be updated.
What if we increase the sync frequency to 24 times per day?
Once per hour (24 times per day), 1.000.000 records are synchronized that each contain 25 fields.
Given the identified profiles visit 3 times per day, on average 125.000 profiles (1.000.000 / 24 * 3) will be updated asynchronously. This will lead to 3.000.000 (125.000 * 24) calls per day to our internal api service.
Upon nightly reporting, only the profiles that have not visited since the last sync will be updated.
Conclusion:
As you can see, the amount of calls to our back-end system highly increases when we have customers that return multiple times per day. Also, due to the amount of identified profiles, the data that has to be synchronized between CRM and Site will also be a lot more.

 

What are consentless visitors and what does this mean for Site?

“Consentless” visitors are visitors that have refused cookies or expressed a desire not to be tracked.

Each action done by a consentless visitor will be considered as a new anonymous hit. Site can target consentless visitors, so marketers can still display offers to all visitors regardless of their preferences - but the range of offer criteria (denoted with the eye symbol) will be limited for consentless visitors.

Marketers are then able to encourage consentless visitors to voluntarily accept cookies or register to receive an improved experience through targeted offers better suited to their behavior in future visits.

Note: Tracking of consentless visitors needs to be activated on request through your Marigoldcontact.

Technical note:
Once the consentless feature is activated, an “isConsentless:false” parameter is added by default to the Site tracking call for every visitor.
If you want to fire offers to these consentless visitors, you'll need to adapt this parameter in the tracking call to “isConsentless:true”.

For these consentless visitors, no (personal or historical) data is tracked or stored, Site does not create any cookie, so no profile is created for them.
Only ‘contextual’ info is being used : the device type, the day of the week, the exit intent, etc. (see the 'Segments > Constraint Editor' topic, mentioned below)
The sole purpose for Site, is being able to fire offers towards these consentless visitors (and define segment constraints), which is not the case without the consentless feature activated, because in that case the whole Site script is blocked.

Linked topics/sections :
- Using JavaScript on your Web Pages > Tracking
- Introduction to Offers
- Define offers > Update Site tracking script
- Segments > Constraint Editor
- Reporting > Real Time View
- New features in Site July 2021 (description + video)

 

Is a tagvalue with "" as value taken into account when pushed to Site

Would the following tagvalue be taken into account when pushed to Site?

Copy 
wa.bt_queue.push({
    "tagValues": [{
        "tag": "Category",
        "value": ""
    }],
    "isEvent": false,
    "isTargeting": false
});

The tagvalue is a key that indicates which Category tag is being hit. If the tagvalue is empty, the system cannot know what Category value was hit and nothing happens. The last known pushed value for this tag will be displayed instead.

 

Where is Site data stored on the end-user devices?

Web browsers have several ways to store data on the user's device. Site has implemented it in such a way that data will be stored in the following 4 places:

  • Cookies
  • Local storage
  • IndexesDB - complete database to store complex data
  • Session Storage - similar to local storage but with the difference that this data expires when the page sessions ends.

Example: Site needs to retrieve the profile ID of the visitor and will try to retrieve it from one of the 4 locations. When Site finds a value for the ID, it will look no further.

The different locations are checked in the order they are listed above.

Because Site has implemented a number of fallbacks for cookies, some endpoints of the JavaScript API will be deprecated in the future:
BT.getDonottrack()
BT.getProfileInfo()
BT.getProfileId()

It is advised to use the following endpoints:

BT.getDoNotTrackAsync()
BT.getProfileInfoAsync()
BT.getProfileIdAsync()