Tracking, goals, targeting, preview, and harness

These command groups support measurement setup, live verification, targeting diagnostics, and external harness preview workflows.

Tracking manifests

apex tracking inspect \
  https://example-store.test/products/example \
  https://checkout.example-store.test/thank-you \
  --shop-id 00000000-0000-4000-8000-000000000020 \
  --out ./.apex/tracking-manifest.json
 
apex tracking plan ./.apex/tracking-manifest.json
apex tracking qa ./.apex/tracking-manifest.json

apex tracking verify accepts comma-separated event types:

apex tracking verify --minutes 120 --limit 20 --event-type pageview,purchase --json

Human output includes a compact, 120-character properties preview for every recent event; use --json when the complete properties object is needed.

Purchase-capture verification runbook

Run the read-only battery after publishing purchase tracking:

apex shops doctor --check purchase_capture
apex tracking verify --event-type goal,conversion,purchase,checkout_completed,order_created --minutes 10080 --json
apex install check --shop-id "$APEX_SHOP_ID"

The doctor verdict is deliberately three-state. OK requires a served purchase plane, a mature publication-anchored window, known historical order cadence, and captured revenue events. DARK means a stage is absent or orders are expected while capture is zero. NO_DATA means the window is too young or cadence is unknown; it is never treated as healthy. The duplicate-order warning starts above 2%. Magnitude mismatch uses |revenue - sum(price * quantity)| > max(0.01, 10% of revenue) as an advisory signal because shipping and tax may legitimately differ. Reconciliation excludes pre-publication and consent-suppressed orders.

Control-goal discriminator

When purchase is dark, add temporary diagnostic, read-only observations for sibling GA4 events already emitted by the page (for example begin_checkout and add_payment_info) and compare them with purchase over the same publication-anchored window. Sibling events present while purchase is absent isolates the checkout-to-confirmation boundary; all siblings absent points earlier, at the data-layer or consent boundary. Do not turn diagnostic siblings into business conversion goals, and remove the diagnostic trigger after the boundary is identified.

Generic rescue patterns

• Session-storage purchase rescue: immediately before a checkout redirect, store the minimum purchase context (stable order ID, revenue, currency, and line items) in sessionStorage. On the confirmed return page, validate and emit it once, then delete it. Namespace the key, set a short expiry, and deduplicate by order ID so reloads cannot double-count.
• PSP redirect-return rescue: when a payment service skips the normal thank-you page, recognize only its verified success-return route, reconstruct the purchase from trusted return-page context, and re-emit the same canonical purchase payload once. Require a stable transaction ID, expire the rescue record, and never infer success from an unverified query parameter alone.

Both recipes preserve the existing write plane; the CLI commands above only observe and reconcile what that plane produced.

Goals

apex goals list --limit 50
 
apex goals create \
  --name "Add to cart click" \
  --type click \
  --selector "[data-add-to-cart]" \
  --count-once
 
apex goals update 00000000-0000-4000-8000-000000000030 \
  --event-name purchase_completed \
  --capture '[{"field":"order_id","source":"property","key":"order_id"}]'

Goal type values are click, pageview, custom, and revenue. Capture can be inline JSON or @path/to/capture.json.

Targeting tests

apex targeting test https://example-store.test/products/example --status all
apex targeting test https://example-store.test/products/example --status draft,running --json

apex targeting test evaluates URL targeting for the supplied page and returns matching count, experiment rows, and caveats from the API.

QA preview URL

apex preview homepage-hero-trust-copy
apex preview homepage-hero-trust-copy variant-a --store-url https://example-store.test/products/example --no-open

apex preview resolves the experiment by ID or slug, defaults to the first non-control variation, and builds a forced QA URL with drip_force, drip_experiment_id, drip_variation_id, drip_qa=1, and drip_debug=1. It opens the browser unless --no-open is present.

AB Test Harness

apex harness init ./ab-test-harness/experiments/homepage-hero
apex harness dev ./ab-test-harness/experiments/homepage-hero --no-open
apex harness publish ./ab-test-harness/experiments/homepage-hero

Set AB_HARNESS_BIN when the harness executable is not named ab-harness on PATH.

Related pages

• Workspace, Operator, and roadmap commands
• Experiment filesystem and QA commands
• Push and GitOps with .drip.config.ts