Overview
Impressions occur whenever a visitor is assigned a treatment (i.e., variations) for a feature flag. Impressions are valuable for debugging the Split SDK and 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 fields
Each impression contains these fields.
Field | Description |
---|---|
Environment ID and name | Environment where the feature flag was evaluated. |
Key | Key which was evaluated. |
Label | Targeting rule in the definition that matched resulting in the treatment being returned. |
Machine IP and name | Machine making the feature flag evaluation. |
Reception timestamp | Time the impression was received by Split. |
SDK and version | Language and version of the SDK that was used in the evaluation. |
Split name | Feature flag (previously, "split") which was evaluated. |
Split version number | 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 feature flag (previously, "split") got picked up by the SDKs and whether one of the SDK instances is not picking up changes. |
Timestamp | Time the customer was served the treatment. |
Traffic type ID and name | Traffic type associated to the feature flag evaluated. |
Treatment | Treatment that was returned. |
Impressions are tracked by each SDK and sent to Split's backend services periodically. If you are not seeing any impressions in Split, ensure that your SDK is installed and functioning as expected. Contact support@split.io if you have any issues.
Note
By default Split retains impression data for 90 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 example, the following is a feature flag 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 feature flag (previously, "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 flag is working as expected. Here are the targeting rule labels for the flag 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:
Special case | Treatment served | Targeting rule label |
---|---|---|
Split was killed | Default | killed |
No rule matched | Default | no rule matched |
Split was not found, for example, it may not have been downloaded by the SDK yet | Control | definition not found |
There was an exception while evaluating treatment | Control | exception |
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.
Additionally, if you don’t want to send a customer UUID to Split as the key, you can hash that ID prior to calling getTreatment. If you decide to hash the ID, be sure to use a deterministic algorithm that results in the same hash value each time. In addition, if it’s important to identify the treatment received by specific users, you must have your own method to be able to associate the hashed value with the actual user ID.
Visualize in Split
Impressions can be found in Split's Live tail in both the Data hub and on a feature flag page. Learn more about Live tail in Split.
Comments
0 comments
Please sign in to leave a comment.