Impression events

April 26, 2019 16:11

Updated

Overview

Impressions occur whenever a visitor is assigned a treatment (i.e. “variations”) for a split. Impressions are valuable for debugging the Split SDK as well as for customer analytics. Impressions are generated by SDKs each time getTreatment is called. They are periodically sent back to Split's servers where they are stored and can be accessed for later use.

Impression event fields

Each impression contains these fields.

Field

Description

Timestamp

Time the customer was served the treatment.

Customer ID

Customer ID which was evaluated.

Split name

Split which was evaluated.

Environment

Environment where the split was evaluated.

Treatment

Treatment that was returned.

Targeting rule label

Rule in the definition that matched resulting in the treatment being returned.

SDK and SDK version

Language and version of the SDK that was used in the evaluation.

Definition as of

Date and time of the last change to the targeting rule that the SDK used when it served the treatment. Valuable in understanding when a change made to a split got picked up by the SDKs and whether one of the SDK instances is not picking up changes.

Change number

Raw timestamp representation of the field Definition as of.

Impressions are tracked by each SDK and sent to Split's backend services periodically. If you are not seeing any impressions in Split, first ensure that your SDK is installed and functioning as expected. Contact us at support@split.io if you have any issues.

Note

By default Split retains impression data for 30 days. Custom data retention policies are available upon request. Contact the team at Split to learn more.

Targeting rule label

Targeting rules can be robust within Split. For instance, here is a split with two rules.

if user is in segment employees then split 100%:on,0%:off else
if user.location is in list ["california"] then split 100%:on,0%:off else

If a user is served the on treatment for this split, the targeting rule label explains which of these rules the user matched. The targeting rule label is the summary of the rule that provides that explanation. The label is auto-generated and is valuable in understanding if your split is working as expected. Here are the targeting rule labels for the split shown above.

Rule

* Targeting rule label*

if user is in segment employees then split 100%:on, 0%:off

in segment employees

if user.location is in list ["california"] then split 100%:on,0%:off else

user.location in list ["california"]

Usually, a treatment is served because the customer matched a particular rule. In this case, the targeting rule label simply indicates the rule that matched. However, in other cases, the SDK serves a treatment even though no rule was matched. This table shows the tarlabel generated in those cases.

If your impression tables are showing not available, consider upgrading your SDK and ensure that labels are enabled in the SDK configurations.

Data security

Labels do not capture identifiable information about your customers. However, if you do not want the Split SDK to capture or send the label back to Split servers, set labelsEnabled to false in the SDK advanced configuration.

Use our integration with Segment and our outgoing Webhook to push Split data into platforms like Google Analytics, Mixpanel, or your data warehouse to quickly understand engagement and other key use metrics.