Estimate the traffic required for success

The Traffic Estimator provides feedback that lets you know whether you have sufficient traffic for your Adobe Target activity to succeed.

Because an Automated Personalization activity uses multiple offer combinations, it is important to know how much traffic is required to provide meaningful results. The Traffic Estimator uses statistics about your page and the number of experiences being tested to estimate the amount of traffic and the test duration needed to make the activity successful.

The Traffic Estimator determines if there is enough traffic to generate personalized models, by comparing the estimated page impressions and typical conversion rate for the pages. Ideally, for a successful activity, the correct sample size ensures that personalized content is ready within 50% of the activity duration or 14 days, whichever is less. This allows sufficient time for obtaining personalized content and learning which content to deliver.

Remember that Target randomly serves experiences until the personalization algorithms are built. The checkmark icon beside each offer shows when the model for that offer is ready and Target is able to begin delivering personalized content. Because lift is expected only after the models are ready, the visual indication allows you to set the right expectation. Use the Traffic Estimator in the Visual Experience Composer (VEC) to get a guideline of when the models will be ready.

Use the Traffic Estimator

1. From the Visual Experience Composer, click Traffic.

   

   The Traffic Estimator opens. You can click Traffic again to hide the Traffic Estimator.

   

2. Provide the typical conversion rate (or the conversion rate you expect from this activity), estimated activity impressions per day, and test duration.

   • Number of Offers: Calculated automatically based on the number of experiences being created as a part of your activity after any exclusions.
   • Typical Conversion Rate: The conversion rate is expressed as a percentage, based on your estimation or past data from your analytics system.
   • Estimated Visits Per Day: This is the number of visits per day from visitors who are able to view the activity, based on the targeting criteria. This could be based on your analytics data. Note this number should be visits, not unique visitors.
   • Test Duration: The number of days you want the activity to run.

   The Traffic Estimator uses these statistics to determine what adjustments are needed to run a successful test.

   Near the top of the Traffic Estimator, the values you entered are calculated and the results are shown.

   

   As you change the numbers, the estimate changes. For example, if you are testing a large number of combinations and your conversion rate and impressions are too low, the Traffic Estimator shows how long the test will need to run to be successful. Or, if your traffic is low, the Traffic Estimator might suggest a lower number of offer combinations so you can run the test the desired number of days.

   If you do not have sufficient traffic, you can do one or all of the following:

   • Consider using an Auto-Target activity instead of Automated Personalization to create experiences with several offer changes in one experience variation.
   • Reduce the number of offer combinations within your Automated Personalization activity.
   • Increase the duration of the activity.

   Adjust the numbers until the Traffic Estimator says you have sufficient traffic, then design your test accordingly.

   

   If the traffic is sufficient, the Traffic icon shows a green check. If it is insufficient, the icon shows a red warning label.

Frequently Asked Questions about the Traffic Estimator

Consider the following FAQs as you work with the Traffic Estimator:

Why is Target not building personalized models when my AP activity has enough traffic?

In certain circumstances, your traffic might be large enough for a personalized model to be built, but that traffic might inform Target that there is no meaningful difference between the personalized model and random. Although the model is built in Target and tested, it will not be deployed because the model is not significantly better than random.

A possible reason for the model not being better than random might be that the offers are not significantly different from each other. If this is the case, you can try making the offers more visually different if the messaging is similar, or you can try changing the messaging itself.