You need to have the different parameters present in your Data Layer, and fetch it from there, within Google Tag Manager. These need to be created as variables, before they can be included in the Collect Code.
The specific implementation details will differ, based on the structure of the Data Layer, so it is difficult to provide an exact specification which you can apply directly.
If you believe your Collect Code is implemented correctly in Google Tag Manager, you can verify use it Chrome Developer Tools. After opening it, go to Network tab, and put igo in the search box. This will show you any calls being made to Collect Code/Marketing Cloud. See an example of this below. This is actually from an implementation where Collect Code is implemented using Google Tag Manager:
You can use collect code as source of data for personalisation. It is critical to understand how this data is stored in your data extensions:
- IGO_PROFILES: Mapping between the native uuid of W&MA and whatever identifier you provide in
setUserInfo call. The provided identifier will always reside in the email field. The customer’s profile will also store what the algorithm
has determined are the top five attributes for which the customer has
the highest affinity. This top five is updated at the end of every
user session.
- IGO_VIEWS: Stores information on when specific products were viewed
- IGO_PURCHASES: Stores information on when specific products were
purchased
- IGO_PRODUCTS: Contains basic information on products
- IGO_PRODUCTATTRIBS: Full metadata on products, derived from catalogue
import
- PI_CONTENTVIEWS: Stores information on when specific
articles/non-product pages were viewed
- PI_CONTENT: Contains basic information on articles
- PI_CONTENTATTRIBS: Full metadata on articles, derived from catalogue
import
Do keep in mind, a product or content catalogue is required before you can start collecting data. It doesn't need to be complete, but at least a baseline PDC with e.g. 10 items needs to be uploaded. Afterwards, you are all good using streaming updates for keeping your catalogue up to date. If you collect an sku or item not in catalogue, this view will not be stored in a data extension. Do observe your attributes in updateItem should correspond to those in the originally uploaded catalogue.
We have the ability to see all data coming in to our data extensions, available for processing. In IGO_PROFILES, we find the identifying attribute (in email column) and a number of calculated affinities can be seen (In Value_X and Attribute_X columns). These are based on internal calculations in Einstein Recommendations, and cannot be altered – hence we have no control which metadata will be selected for affinity calculation.
Do not use email address, but rather a hashed identifier when using setUserInfo call, as providing PII in plain text on a website is not recommended.
It is a very ”quick and dirty” way of segmenting consumers, and whenthis DE gets joined with a DE containing opted-in consumers, wecan produce a sendable DE with an audience, with a specific affinity.
Having detailed information on every single product visit (IGO_VIEWS) allows us – theoretically, to build more complex segments using SQLto lookup e.g. categories in IGO_PRODUCTATTRIBS.However, the volume of the records can make it impractical, and attimes close to impossible.
This is where Audience Builder comes in handy. If you have this as part of your license, it will allow for a drag’n’drop approach to segmentation of subscribers.
It supports a number of data sources – standard and custom, allowing for high degree of flexibility in segmentation criteria. Once initial configuration is done, which needs to be performed by Salesforce Services (Technical Architect) new segments can be easily created without any need for SQL
A created audience becomes available as a Data Extensions, which can be used for e.g. email sendout or Journey Builder entry, and even a DMP segment.
In Audience Builder, sets of segmentation attributes called dimensions, can be combined, allowing to create segments using a combination of a.o. browsing, purchase and email engagement criteria.
For use with Collect Code described earlier, Einstein Recommendations eCommerce Dimension Package should be used.
These examples apply to For Purchase or Browse Events with Product Attributes in Audience Builder.
- Find All attribute name = "Name-Brand Shoes" and attribute color =
"red" Returns all subscribers who purchased shoes regardless of color
and all red items regardless of name
- Find All attribute name = "Name-Brand Shoes" INCLUDE Color = "red" Returns all
subs who have purchased RED Name-Brand Shoes
- Find All attribute Color = "red" Returns anything purchase or browsed with the red attribute
- Find All attribute Name = "Name-Brand Shoes" Returns anything purchased or
browsed with the name "Name-Brand Shoes"
Furthermore, these can be combined with e.g. last open date, number of sends last 30 days, sent by email name or an aribtrary data source, as long as it is available within SFMC.
The advantage of Audience Builder over SQL is both ease of use, and performance - as audience calculations are performed in a non relational database, much faster than MSSQL in which SFMC data extensions are stored. However, given your data volumes are not massive, and SQL skills sufficient, you will be able to achieve comparable segmentations using Query Activities in Automation Studio.
Best Answer
Firstly, SSJS is only applicable if you are running the script on a CloudPage:
Also, you can't simply use variables across SSJS and "classic" front-end JS. How to fetch the subscriber key, I will get back to later.
Your next part is almost correct. I have removed http:, so the script uses same protocol as the page where it is embedded. I have replaced the MID with 12345678 - so you don't disclose the Business Unit where this is running - remember to replace it again with the correct one. You also didn't replace it in the setOrgId function call (it only stated MID in your code).
The following part is the same, regardless if you run the script on Cloud Page or anywhere else:
Next, we need to work with two examples. Firstly, if you run this on a CloudPage, you can fetch the Subscriber Key (I will NOT recommend you use email address or other PII in frontend) if your contact has been sent to the Cloud Page using CloudPagesUrl function:
If you run the script on a different page, you can fetch the id from the url (again - do use anything but email address here). E.g. from http://example.com?visitorid=11001100 you will be able to fetch the id using this script: