You want to prove that personalized sorting actually performs better than your default curation. Instead of guessing, you can set up a direct A/B test comparing a standard Builder template against a personalized one.

This guide walks you through the four essential steps to launch this test.

Instruction & Implementation

Step 1: Verify Event Tag Implementation & Profilekey usage

Personalization relies entirely on user behavioral data. Before configuring the test, you must ensure your application is successfully sending event data to Tweakwise.

• Check your purchase and session_start events.
• Verify that the customer profilekey is consistent across all events and API requests.

Without this, Variant B will have nothing to act on, and rendering your test useless.

Step 2: Create Builder A (Control)

This will serve as your baseline.

• Navigate to Builder in the Tweakwise App.
• Duplicate your current live template or create a new one.
• Name it clearly (e.g., "Lister - Control Group").
• Ensure no personalization components are active.
• Save the template.
• Connect the builder to a category you want to use for the test.

Step 3: Create Builder B (Variant)

This template will contain the hypothesis you want to test.

• Duplicate the template from Step 2.
• Name it "Lister - Personalization Variant".
• Add the Personalization components on positions you want to make dynamic.
• Save the template.

Step 4: Configure and Run the Test

Now you link the two templates to split your traffic.

• Go to A/B Testing.
• Create a new test and select Builder Template as the test type.
• Assign Builder A (Control).
• Assign Builder B (Variant).
• Save to start the test.

Notes & Important Considerations

• Profilekeys & Sticky Sessions: Tweakwise handles the user distribution (bucketing) automatically based on the profilekey provided in the API requests. Ensure your application passes this key consistently on every request.
• Visual Consistency: Ensure that apart from the order of products, the visual layout (tile size, badge placement) is identical between Builder A and B to avoid skewing results based on design differences.
• Data Maturity: Personalization works best when you have significant historical data. If you just implemented the Event Tags (Step 1) yesterday, wait at least 2-4 weeks to gather data before starting Step 4.

FAQ

How do I know if the event tags are working?
You can verify this in the Tweakwise App dashboard. If you see a green check for session_start and purchase, you are ready to go. If you just implemented the Event Tag today, wait a day to see if data is flowing in.

What happens if a new user visits the site (no history)?
If a user lands in the "Personalization Variant" (Builder B) but has no history, the personalization algorithm will fallback to the organic product for that result. This ensures the user never sees an empty or broken page.

Can I test this on just one category?
Yes. In Step 2, you can scope the A/B test by assigning the builder to one or multiple categories. We recommend to do a pilot on a couple of category pages to minimize risk before rolling out personalization site-wide.

My test is working on demoshop but not on production. What can be wrong?
If you have an API implementation, check if the profilekeys are correctly sent. The profilekey in the request should be the same as sent through the event tag events.