2) Scope the data
With a view of what we want to achieve with the trigger we can now work out what data is needed to make it all work. For each area, Entry, Audience, Content list out the data required. Once we have that list we can begin to work out where each data point is going to come from.
Some of our data will already be available in Campaign tables. For example we will need the user’s email address to send them an email, but we won’t be collecting that in the trigger. Other items we will specifically need to use the trigger as the data source – for example if the user has viewed a product page or not.
For certain items it is likely there could be 2 sources available. Take product image. You may already have an existing table in your Campaign instance containing your product catalogue which you can look up by SKU to return an image URL. If you don’t however you may need to collect this off your product pages via Analytics into the trigger, which in turn could mean further TMS or Data Layer configuration.
Other items on the list could be more complicated still. Take “time spent on product page.” You may be lucky enough that your implementation contains a ready configured “time spent on last page” dimension. The issue is that if we send that dimension into Campaign as metadata we will receive “time spent on page” for every page in that visit. Remember, in our example we only want to evaluate time spent on either the swimwear or sportswear pages. We cannot scope this dimension to a particular event unlike Product dimension. Additional processing is required.
The options you have for completing this additional processing are 1) perform processing outside of Campaign to ensure the trigger data arrives in the exact format we need OR 2) perform processing on the data inside Campaign.
Approach 1 is where the Launch TMS can come in useful to do the heavy lifting. By configuring a new eVar which only sends time spent on page when the page is a product page, we can ensure only the data we care about reaches Campaign, and all we have to handle in campaign is logic to return the highest value.
The second approach is to send 2 arrays of Previous Page dimension (time spent on page is sent after the user has moved off the page) and Time spent on Page dimension into Campaign as Metadata, combine them & store them in a table, and then filter that table down to only contain the pages we care about. This is probably going to involve a lookup into another table with the pages we care about. Over time depending on how large the table grows it probably isn’t going to be the most efficient approach here, and involves storing data in Campaign which we don’t actually have any other use for.
In summary at some point you are probably going to encounter a data point you want to use in a campaign which is not fully formed out of the box and requires additional processing. Launch can be a powerful option here to easily solve these kinds of issues, if you have access to that kind of resource, but the solution you opt for will depend on your exact scenario.
Worked Example: Data sources
||User must have viewed either a sportswear or swimwear product page
||Trigger – Page Type evar
||User must not have added any products to basket
||Trigger – Add to Cart event
||User must not have bought any products
||Trigger – Purchase event
||User must have been logged in at some point in the visit.
||Trigger – Account ID evar
||User receives the email relating to the product page they spent the most time on
||Trigger – new product page time spent eVar – Additional launch configuration required.
||User receives an email with the images of the products they have viewed
||Trigger – product SKU scoped to product view > Lookup in campaign.products table