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.
