Journey testing

Journey testing replays a real user flow on your website, like adding a product to a cart and starting checkout, or filling in and submitting a contact form, on a schedule. If a step breaks, you get an alert.

The kind of journey worth testing

Journey tests are best kept to the handful of flows that would genuinely hurt if they broke:

• Add to cart, view cart, begin checkout on a store, ending with an expectation that the payment page loaded.
• A contact or enquiry form, filled in and submitted, expecting a thank-you message.
• Signing in to an account area, where the test uses a dedicated test login rather than a real customer's.
• A search or booking flow, expecting a results page or a confirmation step to appear.

Replay traffic is fingerprinted

TLDTrack marks the traffic it makes while replaying a journey, so you can tell it apart from a real visitor in your own logs, analytics and inbox. Three things mark it:

• An X-TLDTrack-Journey request header on requests to your own site. It is left off requests to other domains, so third-party scripts and fonts still load.
• A distinct browser user agent, TLDTrackJourney/1.0, appended to the usual browser string on every request.
• Any email address a test needs, for example to fill in a contact form, is generated in the shape journeys+<id>-<run>@tldtrack.com, never a real customer's address.

None of this is hidden or spoofed to look like a normal visitor. That is deliberate: it means you can write a simple, permanent filter once, in whichever tool you use, and every future journey test is excluded from your real numbers automatically.

Filtering it out of Shopify

A journey test that adds an item to a cart and reaches checkout does not place an order, so it will not appear as a sale. Depending on what you track in Shopify beyond orders, you may still want to exclude it:

1. 1
   In Settings > Customers, you can identify and tag any customer record created by a test using its email address: every one is in the shape journeys+<id>-<run>@tldtrack.com, so a saved filter or search for journeys+ in the email field finds them all.
2. 2
   If you review cart or checkout events in an app or dashboard that logs by user agent, filter out (or exclude from reports) any session whose user agent contains TLDTrackJourney.
3. 3
   For abandoned-checkout emails specifically, exclude the journeys+ email pattern from that automation so a test run never triggers a real marketing email.

Filtering it out of GA4

Journey test runs load real pages in a real browser, so GA4 will see them unless you exclude them. The cleanest approach is a filter on the user agent, since it is present on every request:

1. 1
   In GA4, go to Admin > Data settings > Data filters.
2. 2
   Create a new filter, choosing internal traffic as the type, or a custom condition if your setup needs one.
3. 3
   Set the condition to match where the user agent (or, if you forward it as a custom dimension, the X-TLDTrack-Journey header) is present.
4. 4
   Set the filter state to active once you have checked it in testing mode for a day or two, so real traffic is not affected first.

If your site does not currently forward request headers into GA4 as a custom dimension, filtering on the TLDTrackJourney user agent string alone is enough on its own, since it never appears on genuine visitor traffic.

Inbox rules

If a journey test fills in a form that sends you an email, that email will carry the test's journeys+<id>-<run>@tldtrack.com address, as the sender, the reply-to address or in the message itself, depending on how your form sends it. A single rule keeps these out of your normal inbox without needing to touch it again as new journeys are added:

1. 1
   Create a new inbox rule (in Gmail: Settings > Filters and Blocked Addresses; in Outlook: Rules) that matches messages containing journeys+ and tldtrack.com in the place your form puts the visitor's address, usually the from or reply-to address.
2. 2
   Have the rule skip the inbox and apply a label such as "Journey tests", or archive it directly, rather than deleting it outright, so you still have a record if you ever need to check one.
3. 3
   Save the rule. Because every journey test email uses the same journeys+ pattern regardless of which journey or site it came from, you never need to add a new rule when you add a new journey test.

Testing as mobile

Each journey test can be set to run as Desktop or Mobile. Mobile replays the exact same steps in a phone-sized browser window instead of a desktop-sized one, which catches problems that only show up on a small screen, such as a button hidden behind a mobile menu or a layout that pushes the submit button off screen. Set this per journey when you create it, or change it at any time from its card in your journey list; the next scheduled run, and any retry of a failed run, uses whichever setting is saved at the time.

What you need before you start

• A website added to TLDTrack to attach the test to (see Add your first website).
• The journey-testing module switched on in Settings, if your team has turned it off.
• A clear idea of the flow you want to check, described in a sentence or two, or recorded step by step with the browser extension.

Where to set this up

Forms behind a captcha

A captcha exists to stop automated submissions, and TLDTrack never tries to get past one. When the page you describe carries a checkbox-style captcha (reCAPTCHA v2, hCaptcha, Cloudflare Turnstile), the test is built differently: it fills in every field, clicks submit, and expects the form's own "complete the captcha" prompt. That prompt only appears after a real submit attempt, so the test can fail, and it proves four things on every run:

• The form renders.
• It accepts input in every field.
• Client-side validation works.
• The captcha widget is healthy for real visitors. A widget showing "ERROR for site owner" blocks every human, and that raises its own alert.

It does not prove that enquiries are delivered. The card above your tests shows one status for each form: Working, Needs attention, Waiting for the first check, Checking again or Checking now.

If you want the end-to-end test on a v2 form, the setting is in the form tool, not in TLDTrack: Tally adds reCAPTCHA as a block you can delete; HubSpot has it under the form's Options > Spam protection; Typeform under Spam prevention; Gravity Forms and Elementor as a field you can remove or switch to v3.

Good to know

• Most failed runs get one automatic retry before an alert fires, so a one-off blip does not raise a false alarm. See alerts and notifications for how you are told.
• A run that stops at a payment form or a captcha is not retried. It alerts straight away so you can adjust the test.
• Turning off the journey-testing module in Settings hides journey tests and their alerts for the whole team. It does not stop scheduled runs, so use Pause on a test to stop it running and using credits.