This article describes some techniques for testing your AudienceStream configuration before releasing it to your production environment.
In this article:
AudienceStream attributes, audiences, and connectors are “live” as soon as they are saved and published. Upon the successful publish, all items will be enriched when the conditions for the enrichment are met with incoming data.
This leads to the common question, “Is there a QA environment to work in so I can test my configuration before going live?” The answer is no, there is no test environment. Instead, there is the ability to place every configuration in a “test mode” that allows you to evaluate it before publishing to production.
To place the configuration of an attribute or an audience into “test mode”, use special conditions that allow you to control when they are triggered.
These following test configurations normally consist of the following 2 items:
This rule is the base for most testing of AudienceStream Attributes & Audiences. It allows the person working on configurations to apply a query string parameter to a session so that they can be identified as a test visitor.
The configuration for the rule is as follows:
IF: data source “Query String” “contains” the text “tealiumtest=true”
In this example, the following url would meet the conditions of the rule:
The “Test Session” badge is used for qualifying an entire session’s worth of data for testing. This comes in handy when you are testing configurations that need to be qualified until a visitor’s session ends. The badge can also be used to qualify a visitor for an Audience so that Connectors can be tested without production data.
This configuration utilizes the aforementioned rule and the configuration of the badge requires 2 enrichments:
Assign Badge: When “Any Event” and rule “Query String tealiumtest=true”
When a user adds this query string to their session, the condition will be met and the badge will be assigned.
Remove Badge: When “New Visit”
This removal enrichment allows the user to keep the “Test Visitor” session through the end of the session. We remove it on the next “new visit” because the Test Visitor should requalify their session as a test session every time. It is not recommended to move forward without this removal logic because you can inadvertently have multiple sessions worth of test data collected which is normally not desired.
A simple example of how these two items apply to future configurations will be illustrated with the following example:
You need to create an attribute for a new variable that is supplying a subscriber’s “First Name” after they log-in.
Data such as a person’s First Name should be stored as a string, so the example configuration of this attribute will be using the “string” Attribute type:
Set String to: variable “first_name”
WHEN: “Any Event”
AND “first_name is Assigned”
AND “badge Test Visitor is Assigned”
The conditions in this configuration will only allow the string to be set when the variable “first_name” is assigned and the Test Visitor badge has been added to a user’s session.
Now you must test your configuration to ensure it satisfies what you are trying to achieve. First, you have to ensure the configurations you have made are saved and published. Then the user will need to utilize AudienceStream’s Trace Tool to validate the configuration.
To test, the user should take the following steps:
When you are ready for this configuration to go live, go back to the First Name string and remove the condition for “badge Test Visitor is Assigned”. Then save and publish your update. Once publish is completed, your First Name string attribute will populate for every visitor moving forward.