Launch your first personalization

Prepare the page, access, and success check

Use common setup first. You need an installed tag, permission to edit the selected AXO site, and an owner or admin who can enable review before publishing. For the preferred workflow, complete Claude, AXO skills, and Chrome setup. If browser access or the skills are unavailable, use the dashboard picker to bind the zone.

Write down the homepage URL, original headline, replacement headline, and one existing outcome you want to improve. For example, use “Welcome. Find the right option for you.” while leaving the existing button and its destination unchanged. Use copy appropriate to your own offer.

A zone identifies the page area; a variant holds replacement content; its eligibility rule decides which visitors can receive it. A goal records the business outcome. Saving these objects alone does not prove that any visitor saw the headline or completed the goal.

Before generating browser visits, request the test environment and evidence below. If it is unavailable, prepare and preview the draft, then hand the delivery checks to the named operator. A completed preview leaves audience and goal delivery pending.

Request an environment for delivery checks

Send this request to the account owner or AXO support. A site label, query parameter, or promise to delete test data does not supply isolation.

Please name the operator and provide an approved QA environment or isolated local fixture for this homepage test. Confirm the exact hostname, AXO site, and build; how generated activity is prevented from reaching production reporting, goals, optimization, CRM/email/advertising destinations, and billing; and whether the setup can verify event delivery or only rendering. Return the isolation evidence before browser navigation. Please prepare clean browser contexts for the new/returning and organic/paid cases, plus a bounded check of treatment and holdout behavior.

There is no sandbox-provisioning step in this tutorial. The operator must identify a supported mechanism. Verified request interception installed before navigation can block telemetry while allowing read-only assets and configuration; that setup proves rendering only. Agent-led checks must use an approved AXO QA target or local fixture, never a live client site. If isolation cannot be verified, do not generate visits.

The operator returns a case-by-case report with the environment and build, saved configuration, visitor-state setup, timestamp, visible result, read-only render diagnostics, and any isolated event receipt. Mark unavailable checks pending with that operator as owner. If a correctly bound zone already exists, continue with draft creation and the available private preview. Otherwise, complete the copy and outcome plan, and leave binding and appearance checks pending with the operator.

1. Choose an outcome you can observe

1. Open Account Settings → Conversion goals. Read the existing primary goal before changing anything. It drives the site's headline conversion result.
2. For a completed signup with a dedicated confirmation page, use that page's actual path as a URL goal. On a site with no goal, enter it under Custom URL pattern and click Set. On a site with a primary goal, use Add supporting goal, enter a name and the confirmation path, then click Add.
3. If signup completes without changing the path, have the site developer instrument the confirmed success event and follow the custom-event instructions. A button click or an attempted submission can occur without a successful signup.
4. Reload the settings and confirm the saved detection rule. Check the goal's recent activity indicator when eligible events arrive. A saved rule with no events is still awaiting delivery evidence.

Use an existing goal that fits your task if the site has no signup flow. Record which exact event or page demonstrates completion. Installing the tag does not establish that external CRM outcomes or every embedded form are connected.

2. Keep the first version private

1. Select the intended site, then open Publishing.
2. Turn on Review before publishing and confirm that the saved setting is on. This changes publishing behavior for the whole selected site, so coordinate it with anyone already editing content.
3. Keep the setting on throughout this tutorial. In the default automatic mode, saved content can become eligible for visitors. Turning review off later releases pending edits across the site.

On an already live site, enabling review preserves the content currently being served. It does not undo earlier live edits.

3. Bind only the homepage headline

Replace the example URL in this prompt with your homepage. Use the permitted browser environment established above.

Use the AXO zone-binding skills and Chrome for the selected site. Check existing zones first. Bind the homepage hero at https://example.com/ as “Homepage welcome,” applying only to the homepage path /. Keep the headline as the only editable field. Show the saved zone ID, page pattern, selector, and headline field key. Confirm which bindings you verified. Leave existing content and publishing unchanged.

Open Zones and confirm the saved name, homepage pattern, and headline binding. A broad pattern such as * would also allow other paths. A field pointing at the wrong element needs correction before you author content.

If a matching zone already contains other live experiences, choose an unused page area or coordinate the change with its owner. The stop control later in this tutorial pauses the entire zone.

4. Create the welcome variant for new organic visitors

For this example, “new” means AXO found no existing visitor cookie when the tag started on this page. “Organic” means the arrival has no recognized paid-ad signal. This describes the browser state AXO can observe; it does not establish that the person has never visited on another browser or device.

Ask Claude to create the following draft using the saved zone ID. The rule is included so its meaning can be checked without relying on an audience name.

Read the saved Homepage welcome zone and confirm review before publishing is on. Create one private copy_swap variant using the exact headline field key in that zone's field_schema. Set the headline to “Welcome. Find the right option for you.” Use eligibility {"kind":"visitor_lifecycle","status":"new","acquisition":"organic"}. Keep all other content and links unchanged. Check for an existing matching draft before creating one. Show the saved variant ID, headline, eligibility, and publish state. Do not publish it or activate the site.

Open Content → Homepage → the zone. Confirm the headline and Draft state. The API creates the needed New visitors reference for this rule, so you do not have to create a behavioral segment first. The dashboard may show Advanced eligibility; that rule is preserved when editing copy. Ask Claude to inspect or change it rather than replacing it with an unrelated Target Segment.

New visitors from recognized paid-ad arrivals and returning browsers are excluded. A full page reload after AXO has stored its visitor cookie can already be a returning-browser case. Browser storage restrictions and identity handoffs can affect the classification.

5. Check appearance before publishing

1. In the zone editor, choose Draft in the preview. Use Preview variant to select the saved welcome variant explicitly.
2. Check the exact replacement headline at Desktop, Tablet, and Phone widths. Confirm the button, destination, surrounding content, and layout remain correct.
3. Compare Live to see what is currently published. On a new zone, the welcome variant should still be absent from live content.
4. Use Share preview if someone else needs to review the appearance. Correct mistakes in the draft and wait for its save status before repeating the check.

Selecting a specific preview variant forces that content to render and bypasses its audience rule. This proves appearance only. It cannot establish that a new visitor qualifies, a returning visitor is excluded, or the goal is delivered.

6. Publish the reviewed variant and activate delivery

1. Choose Publish changes, inspect the selected variants and differences, then choose Publish now. Publish only the variant you reviewed. Confirm its state is Live.
2. Confirm the zone is approved in Zones. Publishing content and approving a zone are separate requirements.
3. If the site is in Pre-launch, review all approved zones and eligible published content with the site owner first. Go Live enables personalization across the site, including other prepared experiences. Resolve unreviewed content or ownership before activation. Then open Launch, resolve its installation, zone, and variant checks, choose Go live, and confirm Go Live.
4. Allow updated configuration to reach a newly loaded page. A saved change does not rewrite every page already open in a visitor's browser.

A live variant is eligible for delivery. The holdout group intentionally keeps the original experience, and another eligible variant or experiment can affect selection. Keep this first exercise to one candidate in an otherwise unused zone.

7. Verify delivery, exclusions, and the goal separately

Have the named test operator run these checks only after isolation is verified. Keep ordinary delivery checks free of forced-variant, forced-segment, and debug settings; these can bypass selection or holdout. Preserve each case's URL, visitor-state setup, zone and variant IDs, time, and observed result.

1. Start an organic case in a clean isolated browser context with no AXO visitor cookie or stored arrival state. Load the approved homepage URL without gclid, fbclid, or a paid utm_medium. Record the result, then fully reload the same context after confirming AXO stored its visitor cookie. The reload supplies the returning-browser case.
2. Start a separate clean isolated context at the same homepage with ?utm_medium=cpc (use &utm_medium=cpc if it already has a query). The tag classifies cpc as paid. Save the actual loaded URL. The previous context now has a visitor cookie and would test a returning browser, so changing its query would not establish the new paid-visitor case. This parameter sets the case; it does not isolate telemetry.
3. Read the diagnostics below for treatment and holdout evidence. If the bounded check produces no held-out case, leave that case pending and ask the operator to exercise it in a controlled local fixture. Do not keep clearing identity, change the production control rate, or enable debug mode to manufacture a result.

The developer or test operator can open the browser's developer tools, choose Console, and run these read-only calls after the page loads:

window.axo?.getDecisionContext?.()
window.axo?.lastRender?.()

getDecisionContext returns the site-level gate: holdout, eligible, blocked, backtest, or unavailable. “Eligible” does not prove this variant's audience matched. In lastRender().entries, find the saved zone_key: ok or ok_healed records a successful application; skipped_holdout records holdout; skipped_no_variant records that no candidate was selected. A null snapshot means no completed personalization pass is available. An absent method means that tag build does not expose it; use the available render outcome or leave the check pending.

If you cannot use the console, send the zone ID, test time, and isolated session ID to the operator and request those outputs. With event access, Claude can use explain_variant_exposure for that session and zone to read persisted evidence; preserve any “unknown” conclusion. The server trace cannot reconstruct the browser's original new-visitor flag. Ask for the matching goal event separately. See the browser API reference for session IDs and render diagnostics.

Record “rendering verified,” “audience delivery verified,” and “goal delivery verified” independently. If telemetry was blocked for isolation, goal delivery remains unverified. Test and owner activity must be excluded from customer-demand and lift claims. Read Performance and lift when real eligible visitors accumulate.

8. Diagnose a failure and stop the experience

1. To stop this experience, open Zones and choose Pause for the Homepage welcome zone. This stops all variants in that zone from being served in updated ordinary configuration.
2. Reload Zones to confirm the saved state, then verify a fresh ordinary page after it receives updated configuration. Existing open pages can retain previously rendered content.
3. If other content shares the zone, ask Claude to disable only the saved variant with update_content_variant and active: false, then inspect its saved state. Keep the variant ID from the earlier step so the intended row is unambiguous.
4. Correct the draft, preview and publish the intended version, then deliberately resume the zone or variant. Resuming can serve its already published content without another publish step.

Turning review off releases pending edits; it is not a rollback. Retiring an audience is also insufficient to stop variants already targeting it.

9. Adapt the recipe to a second use case

Change one decision at a time. For another page, rebind its actual headline and use its exact path. For a different audience, specify the observable condition and repeat one qualifying and one excluded case. For a different outcome, confirm its event delivery before interpreting results.

Continue with audience rules for stored behavior or customer attributes, campaigns for coordinated content and dates, or your first trigger for an action after an event. Each adds dependencies that the homepage exercise did not require.