I’ve got an audience built around days since conversion. Data is inputting into Tealium via an Omnichannel file – which includes the date of the event.
I then have audiences for within 180 days of the event and over 180 days of this event. These audiences are then fed to media vendors to make suppression lists.
I’m not clear on how the transition between these audiences would be set. Is there a process whereby existing audiences are tested to allow for an in/out decision made as to which audience records should be in as they hit that threshold date.
Does this happen automatically? If so, when does it happen?
Solved! Go to Solution.
11-01-2019 04:18 AM - edited 11-01-2019 04:19 AM
With a couple of notable exceptions that I will explain here, AudienceStream is purely an event driven system that operates at the individual visitor profile level.
What this means is that visitor profiles only change state when an event individually enriches that visitor profile.
More concretely in your example, let's say;
You define a Visitor Level date to capture the event date
You base an Audience on a rule to say this date must be within the past 180 days
You fire a connector action on users joining the audience and another connector action on users leaving the audience.
This will work - users will fire both connectors, but there is a subtlety - users will have to have another event (either return to the site or app, or be enriched with an offline event) in order to leave the 180 day audience and fire the "leave" connector.
If your use case can't rely on that happening, then you need to look at alternative approaches.
One approach is to use delayed connector actions. These are documented here - https://community.tealiumiq.com/t5/Universal-Data-Hub/Delayed-Actions-for-Connectors/ta-p/17575
What you'd do in that case would be to fire your Joined Audience connector as normal when the user joins the audience. However, instead of the Leave audience connector, you'd instead set up another connector action based on "In Audience at End of Visit", choosing the "Was not in Audience at beginning of visit" option, and specifying a delay of 180 days. This means 180 days after joining the audience, this delayed connector would fire, and you could remove the user from retargeting or whatever at that point.
Delayed connectors will only fire if the user is still in the audience at the point in the future where the delay timer actually runs down to zero. So depending on your use case, if there is a way for the user to leave the audience in the meantime, you may want to set up a conventional "Leave Audience" connector action to catch that as well.
Also note with delayed connectors that they use the visitor profile as it will be at the point in time in the future when the delay runs down to zero. So don't pass visit level attributes (because they won't be in scope then) and make sure you are happy that visitor level attributes you want to pass will still have the desired value at the point in the future. This consideration is only relevant if you are actually passing payload to the connector. If you're simply removing someone from a retargeting list, you probably don't care about this.
Another approach to look at would be AudienceSizing, which is detailed here - https://community.tealiumiq.com/t5/Universal-Data-Hub/Audience-Sizing/ta-p/13781. This also allows you to get away from the event-driven nature of AudienceStream. It currently isn't automated, so you'd have to run the job manually each time you wanted to. However, Tealium are working on making this automated/scheduled. I don't have an ETA on that, though.
With either of the two approaches above, you need to check that your visitor and/or audience retention period is longer than 180 days - see here https://community.tealiumiq.com/t5/Universal-Data-Hub/Building-an-Audience/ta-p/11881
Just for completeness, another option would be to use the vendor system to handle the 180 day expiry. Many retargeting system will allow you to specify that list membership expires X days after joining the list. In fact, it's worth checking if this will automatically be applied before you assume that the user would stay in the list for 180 days in the first place.