Before You Begin
Ensure you have:- Access to Auxia Console
- At least one treatment created (Draft or Published)
- A test User ID for your use case (the specific user identifier used in your integration)
How QA Works in Auxia
If you’re coming from a traditional marketing platform, QA in Auxia works a bit differently. In most tools, testing means sending a proof to yourself or toggling a preview. In Auxia, QA is more structured because there’s more to validate - treatments are personalized, governed by eligibility rules, and selected by AI models. Auxia’s QA workflow breaks down into two types of testing:Tip: For a first-time launch, run both. For content-only updates, Rendering QA is usually sufficient.
Rendering QA: Verify How Treatments Look
Step 1: Set Up QA Users
QA users are test accounts designated in Auxia’s QA system. Once a user is set as a QA user, all normal rules stop applying - they can and will receive whatever treatments are assigned to them, even if those treatments are in draft or paused status.- Navigate to Treatments & Journeys > QA and Testing
- Click Add QA Users in the User Configuration tab
- Enter the User ID for the QA user (this must match the user identifier for your use case)
- Optionally add QA tester names and tags for grouping
- Assign specific treatments to each user in preferred order
- Click Save
Important: Changes take up to 5 minutes to propagate after saving. Maximum 100 users can be inserted, reset, or assigned at a time.Good to know:
- QA works even for draft or paused treatments
- QA ignores qualification criteria - the treatment will be sent regardless
- If the user is missing data for a personalization field, the treatment still sends - the raw field string (e.g.,
${personalization_field_1}) will be displayed instead
Step 2: Send a Test Treatment
The next step depends on the type of surface your use case targets. In-app / web-based surfaces (banners, carousels, in-app messages): No manual triggering is needed. Once a QA user is configured with an assigned treatment, that treatment will automatically appear whenever the user navigates to the in-app or web surface. Out-of-app delivery (email, push notifications): You need to manually trigger delivery using the Test Treatments page:- Within QA & Testing, click Test Treatments
- Enter the QA User ID (must match the User ID from Step 1)
- Optionally set contextual attributes
- Set Maximum Treatment Count (up to 10)
- Click Run Treatment Test
- If the status shows “successful”, the treatment has been delivered to the specified surface
Step 3: Verify the Treatment
Check the following on the target surface: Email:- Renders correctly across email clients (Gmail, Outlook, Apple Mail)
- Personalization fields show correct data (if a field shows a raw string like
${field_name}, the user is missing data for that field) - Images load properly
- Links and CTAs point to the right destinations
- Unsubscribe link works
- Delivered to QA device
- Title, body, and image display correctly
- Deep link opens the correct page on tap
- Renders in the correct position on the page
- Displays correctly across screen sizes (mobile, tablet, desktop)
- Dismiss behavior works
- Clicks point to the right destination
Guardrail QA: Verify Who Sees Treatments
Testing Eligibility
Eligibility testing checks whether a specific user qualifies for a treatment based on its qualification criteria.- Navigate to the treatment on the Treatments & Journeys page
- Click Test Eligibility
- Enter the User ID
- Click Test - this reveals whether the user qualifies and why
- Positive test: Use a user who SHOULD qualify. Verify they do.
- Negative test: Use a user who SHOULD NOT qualify. Verify they don’t.
- Boundary test: Test edge values (e.g., if the rule is “days_since_signup < 7”, test with exactly 6 and exactly 7)
Running a Simulation
Simulation validates your configuration at scale before going live. It tests a sample of your user base against your treatments.- Navigate to the Simulation page in the console
- Define the number of users to include
- Select the treatments to test
- Click Run Simulation
- Review the results
- Treatments with personalization fields appear in results
- The percentage of eligible users aligns with your expectations
- Treated vs. Control group splits match your experiment design
- Traffic allocation matches your configuration
- 0% qualification rate - rules may be too restrictive or personalization fields may be missing
- 100% qualification rate - rules may be too broad or missing entirely
- Skewed distribution - may indicate model bias or priority misconfiguration
Troubleshooting
Treatment does not send to QA user
- Verify the QA User ID matches exactly (case-sensitive)
- Wait 5 minutes after saving for propagation
- Confirm the treatment is assigned to the QA user
- For in-app/web surfaces: confirm the user is navigating to the correct page
- For email/push: confirm you’ve triggered delivery via the Test Treatments page
Personalization shows raw field strings (e.g., ${field_name})
- This means the QA user doesn’t have data for that field - the treatment still sends, but displays the raw string
- Check that personalization field names match exactly in the treatment configuration
- To see proper personalization, use a QA user that has data for those fields
Simulation shows unexpected distribution
- Review qualification criteria for each treatment
- Check for overlapping or conflicting eligibility rules
- Verify personalization field coverage across your user base