Use Split's dependency matcher when you want one split to depend on the evaluation of another split.
Here is an example. We have two splits with the second depending on the evaluation of the first. We want 20% of customers who receive on for the
new_homepage split to evaluate to on for the
advanced_news_feed split while the other 80% should evaluate to off.
Split's dependency matcher is located in the condition string to meet your most granular targeting needs.
As you begin to use the dependency matcher, a few things become clear:
- Environments and traffic types: The dependency matcher does not allow you to depend on another environment's condition or target across traffic types.
- Circular dependencies: Split prevents you from creating a direct circular dependency by not displaying those splits that would create a circular dependency.
- Attributes: If split B has split A as a dependency, the
getTreatmentcall for split B must pass all of the customer attributes needed to evaluate split A. Split B's syntax modal displays all of the attributes needed to make the evaluation successful.
- Deleting: You cannot remove a split from an environment or delete a split if additional splits depend on that split for their evaluation.
Here are some common questions.
- Does the dependency matcher count as 2+ evaluations? No, the evaluation is counted as one single evaluation and does not fire off multiple calls or register multiple impressions.
- There is a warning in the UI when I use a dependency matcher. What does this mean? The warning you are seeing is to warn you that if the dependent split requires additional attributes. You need to update the
getTreatment()call to include those attribute values. The syntax model displays all of the attributes required to make the evaluation successful.
- Do parent splits know which child splits are using it in their evaluation? Yes, if a split is being used as a dependent, Split's web console informs you in the editor. You cannot delete the split, or delete or rename treatments.