Sort & Limit
Sort & Limit allows you to sort records, either randomly or by a specific field, and restrict the total number of records returned to an exact number or percentage. In standard SQL terms, it acts as the equivalent to the LIMIT and ORDER BY statements. This feature is useful for generating random samples or splitting audiences into controlled groups for A/B testing.
Unaric Segment always runs Prio DeduplicationPrior Deduplication before Sort & Limit to ensure duplicate records are properly removed before the final sample limit is applied. Otherwise, if random sampling was to run first, then some duplicates could be removed by this process without using deduplication rules.
Set up A/B testing with Sort & Limit
Use Sort & Limit to split your audience into test groups for controlled experiments.
- On the Output step, click Tools.
- Select Sort & Limit.
- A modal will appear where you can:
- Sort your data (randomly or by a specific field like email address or last name).
- Limit your data by selecting a number (e.g., 10,000 contacts) or a percentage (e.g., 50% of the total records).
- Click Save to finish.
Example
This example scenario will test two email subject lines to determine which one gets a higher open rate. The total audience has 100,000 email subscribers.
- Create Group A (50%)
- Create a Selection with all 100,000 contacts.
- Open Sort & Limit and set:
- Sort by: A specific field (e.g., Contact ID, Email Address, or Last Name).
- Limit: 50% of records.
- Create Group B (Remaining 50%)
- Create a second Selection with the same dataset.
- In Sort & Limit, apply:
- Sort by: The same field as in Group A.
- Limit: 50% of records.
- Filter out contacts already included in Group A (e.g., use a greater-than/less-than condition on Contact ID).
- Send emails
- Assign Email Subject A to Group A and Email Subject B to Group B in Salesforce Marketing Cloud.
- Analyze results
- Compare open rates and click-through rates to determine which subject line performs better.
How Sort & Limit handles primary key duplicates
- The Sort & Limit feature is applied at the query level before data is saved to the Target Data Extension. If the target has a primary key, the system automatically drops duplicate records upon saving, which causes Sort & Limit to return fewer results than expected.
- The solution: To avoid this unpredictable behavior, users should use the Prio Deduplication feature.
- The execution order: Unaric Segment is specifically designed to run Prio Deduplication first, and then apply Sort & Limit. This ensures that random sampling or limits are applied to a clean dataset, yielding the exact expected record count.
A primary key is a field—or combination of fields—that acts as a unique identifier for each individual record within a Data Extension, such as a Customer ID
. Because a primary key must be entirely unique, the system automatically removes any duplicate records sharing the same primary key when saving data into a Target Data Extension
. Additionally, designating a primary key is required when using the Update Data Action, as it serves as the reference point the system uses to check whether a record already exists
.
Let's say you have two Data Extensions, one that contains customer information and one that contains order information as shown below:
CUSTOMERS | |||
|---|---|---|---|
ID | First Name | Last Name | |
ORDERS | |||
|---|---|---|---|
ID | CustomerID | Order Date | Amount |
The two Data Extensions are matched using the ID column from the Customers Data Extension and the CustomerID column from the Orders Data Extension. In total, you have 60 rows in your Customers Data Extension and 300 rows in your Orders Data Extension. One customer can have many orders and all CustomerIDs inside Orders Data Extension exist in the ID column of Customers Data Extension.
You want to get all customers that have placed an order, alongside an order's information, so you add those two Data Extensions to your Selected Data Extensions and only keep the matched fields of the two Data Extensions (INNER JOIN) and store the results in a Data Extension that looks as follows:
CUSTOMERS WITH ORDERS | |||||
|---|---|---|---|---|---|
CustomerID | First Name | Last Name | Order Date | Amount | |
Where CustomerID is the primary key of the Data Extension.
After running your selection you get 60 results. But afterward, you decide you would like to perform an A/B test so you decide to use the Sort & Limit functionality to randomly select 50% of your results and rerun, but still get 60 results on your selection.
The reason behind this is that Sort & Limit is applied to the query level before the data are saved inside the Target Data Extension.
When the Data Extensions are combined they actually generate 300 results, and the CustomerID field is not unique. When the data are getting saved inside the Target Data Extension the duplicates are being removed, since CustomerID is the primary key and it must be unique, and you end up seeing only 60 results.
So, when you apply Sort & Limit the number of results you see will be half of the originally generated data. In this case, what happened is that the original query generated 300 results, so half of that would be 150 rows, and when those were stored in the Target Data Extension the duplicates were removed and you got again 60 rows.
Keep in mind that the opposite might happen as well, you might see a smaller amount of results than the one expected in case of duplicates in a primary key column that got removed.
To avoid such unpredictable behaviour, it is recommended to either use our Prio Deduplication feature or make sure that when dealing with one to many relationships, you use as the primary key of your Target Data Extension the primary key of the latter (in the example provided ID of Orders Data Extension)