Q&A
What do I need to do to identify my website visitors as CRM identified visitors?
How can I create Site reporting segments including data from my Campaign environment?
How can I use Campaign information in offers?
How can I use my Site information in Campaign?
If the name of the tag changes, does this mean that all values are lost?
If I use offers, does Site change the structure of my website?
Can I use completely different domains in one universe?
Is there any approval workflow?
Is there a direct access to data stored in the Site tables and possibility to export these?
Can a user select manually a period on a graph?
Do we have AB-test possibilities?
Can we have multiple lists in one universe?
What happens when we change the main audience list in the universe? What impact does it have?
How long is data stored within Site?
What synchronisation processes exist and what is their frequency?
Is a tag pushed to Site, when the tracking call value is empty?
Where is Site data stored on the end-user devices?
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 Campaign environment.
How can I create Site reporting segments including data from my Campaign environment?
Site reporting segments can use Site profile data, tag information and also CRM data. CRM data refers to Campaign information. To be able to access these Campaign fields in Site, it is required to
- Create a REST API user, tick the option ‘Connect to Campaign’ for the universe and enter credentials to connect.
- Select the Audience from where data must be retrieved.
- Select the fields in the selected Audience that must be made available for the segment definition
How can I use Campaign information in offers?
- Campaign 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 Campaign fields for Site segments. See previous
question)
- For Offer actions of type HTML
or popup/popin a Campaign '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.
- In Offer activities and conversion
a CRM page tag can be selected.
The Site tracking script must be on the Campaign page.
Example: Typically this would be a Campaign page that is used in the Site, 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 Campaign.
- For Offer follow-up and retargeting, a Campaign retargeting Journey can be selected.
How can I use my Site information in Campaign?
Information from Site can be exported to Campaign, and created as a profile extension to an audience list. To do this
- Create a REST API user.
- Check ‘Connect to Campaign’ for the universe and enter credentials.
- Select the Audience in Campaign for which a profile extension must be created
- 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 Campaign 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.
- Expose Site profile data, tag values and CRM data to the front-end.
- Request the tracking data in Site’s tracking call and use this data in a call-back function.
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 sites.
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. However, it is not possible to manually select a winner. Once there is a significant winner, that one will be selected.
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 Campaign user.
3. One universe - multiple tables
Not recommended. If one device can be linked to multiple Campaign 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 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 Campaign 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 CampaignID (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 that don’t use CRM fields , the audience will not be affected.
If you have active offers that do 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 Campaign, 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 Campaign.
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 Campaign 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 Campaign; If the export is set as 'merge', the Campaign profile will remain. If the export is set to replace the data, then the Campaign 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 Campaign 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.
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.
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()