Conversion Intelligence Lab

Measurement readiness

Load real performance data

Automatic captured clicks

If private export is configured in Cloudflare, load aggregated click events directly. The admin token is held only in this browser session and is not stored by this page.

Or continue with CSV upload below.

Trend Watch

Compare the most recent period with the immediately previous period of equal length. This watches click direction only; it does not infer revenue or statistical significance.

Uses the same private export token entered above.

History guardrail: V29 suppresses directional alerts until two complete comparison periods exist. After that, the default alert guardrail is previous period ≥10 clicks, absolute change ≥5 clicks and relative change ≥40%. “New volume” requires at least 10 current clicks with zero in the previous period.

Use the two templates below. Click data should come from your analytics event export; transactions can come from Awin's Publisher Transaction Report. The join key for Awin is click_ref / clickref.

Scale / Hold / Fix / Stop engine

This V29 layer joins the current click period from Trend Watch with real Awin transactions by unique clickref. It uses approved commission only for realized EPC. Pending commission is never counted as earned revenue.

V29 thresholds: Scale requires at least 15 current clicks + 2 approved transactions + positive approved EPC and no decline signal. Fix begins at 20 current clicks with no approved/pending transactions. Stop is deliberately strict: at least 60 current clicks, mature history, confirmed full Awin window, and zero approved/pending transactions. “Stop” means pause scaling and verify attribution/advertiser validation before removing a CTA.

Profitability ranking: pages & merchants

V29 aggregates CTA-level evidence into two decision layers. Page ranking answers where to add internal authority, traffic or CTA exposure. Merchant ranking currently answers which Awin advertiser deserves broader coverage, because realized transaction imports in V29 come from Awin. Approved commission and EPC are ranked inside each currency only; currencies are never silently combined.

Page profitability

Awin merchant economics

Internal-link recommendation guardrail: a page must have at least two approved transactions, positive approved EPC, mature history and a confirmed transaction window. “Increase internal links” is reserved for proven pages below the current monetized-site median of 17 internal inlinks. V29 generates recommendations only; it does not rewrite site links automatically.

V29 Awin Advertiser Quality

Before blaming a page for weak affiliate results, compare its first-party economics with the advertiser programme context that Awin exposes: membership/link status, Awin Index, approval percentage, programme EPC, conversion rate and validation days. V29 does not invent a replacement quality score; it displays Awin's own Index and keeps any additional thresholds explicitly labelled as internal operating policy.

Live mode is optional. Configure AWIN_ACCESS_TOKEN as a Cloudflare secret and AWIN_PUBLISHER_ID as a server-side variable. Manual JSON import remains browser-only.

Interpretation guardrail: PROGRAM_BLOCKER can stop new scale when membership is not joined or Awin reports the programme link offline. VALIDATION_WAIT delays page blame when pending evidence exists. PROGRAMME_WATCH uses AI Video Signal's internal watch levels—not Awin sector benchmarks—and never reduces traffic automatically.

V29 Root-Cause Router

Combine page economics, traffic direction, Awin programme quality and pending-validation age to decide where the next investigation belongs. V29 routes evidence to Merchant, Validation, Attribution, Page, Traffic, Release or Control; it does not auto-edit pages, replace merchants or move traffic.

Merchant root-cause routing

Page root-cause routing

Validation-age guardrail: Awin validationDays is treated as an average, not a contractual deadline. V29 uses an internal 7-day tolerance for normal pending review and a 14-day over-average threshold only to trigger VALIDATION_REVIEW; it never treats an old pending transaction as proof that the advertiser failed.

V32 Root-Cause Remediation Queue

Turn each V29 root-cause route into one controlled primary intervention. The queue assigns priority, logical owner, evidence required to close the task and an explicit do not do guardrail so a merchant/validation issue cannot accidentally trigger a page rewrite.

One-cause/one-action guardrail: V29 never combines a merchant switch, CTA rewrite and traffic change into one task. VALIDATION/WAIT tasks collect evidence; RELEASE tasks contain/verify the release; PAGE and TRAFFIC tasks require controlled experiments; CONTROL protects the baseline before any scale test.

V32 Remediation Outcome Ledger

Close the loop on each remediation task with an append-only lifecycle: Opened → Action applied → Resolved / Monitoring / Escalated → Reopened. V32 preserves the V30 before/after snapshot lifecycle: it freezes the task snapshot when the issue opens, captures a comparable snapshot at outcome time, and adds durability checks below.

Local browser persistence works immediately. When AUDIT_DB and the private token are configured, events are also appended to the existing tamper-evident D1 audit chain.

Closure guardrail: V32 does not allow a direct jump from Opened to Resolved. Record the real action first. Resolved/Monitoring/Escalated require an evidence note and preserve both snapshots; Reopened appends a new event instead of overwriting the previous conclusion.

V32 Remediation Effectiveness & Recurrence Control

Re-check concluded remediations after time has passed. V32 distinguishes stable resolution, provisional success, recurrence risk and root-cause shift. It never reopens a task automatically.

Internal guardrails: at least 7 days before recurrence/stability assessment and 14 days without matching P0/P1 recurrence before calling a resolution stable. These are operating thresholds, not statistical proof.

V32 Remediation Cost & Priority Intelligence

Rank remediation work using approved commission exposure, severity, recurrence and an operational effort proxy. V32 never invents staff cost, hours or ROI, and it never compares commission totals across currencies.

Priority guardrail: approved commission is an exposure signal, not guaranteed future loss. LOW/MEDIUM/HIGH effort is an internal operational proxy only. Currency groups remain separate; mixed-currency rows cannot receive an economic component.

V33 Remediation Work Queue & Conflict Control

Sequence remediation work after V32 priority scoring. V33 keeps already-open work active, exposes dependencies, and prevents page/traffic work from jumping ahead of unresolved release or merchant blockers. It does not execute tasks automatically.

Conflict guardrail: active remediation is continued rather than duplicated. RELEASE blockers can hold dependent PAGE/TRAFFIC work; MERCHANT/ATTRIBUTION blockers can hold dependent page work. This is sequencing logic, not automated execution or a staffing-capacity estimate.

V34 Work Queue Throughput & Internal Service Guardrails

Measure how long remediation work has been waiting or sitting without a recorded lifecycle event. V34 uses internal aging targets only to surface stale work and aged blockers; it does not promise external SLAs, estimate staffing capacity, or auto-escalate anything.

Internal aging policy: P0 1 day, P1 3 days, P2 7 days, P3 14 days. “Breach” means the queue needs review; it is not proof that a person or provider missed a contractual SLA.

V35 Aging Escalation & Bottleneck Control

Identify remediation tasks that block the largest amount of downstream work. V35 combines internal aging guardrails with dependency fan-out and P0/P1 severity to surface the blocker that deserves review first. It does not bypass dependencies, change lifecycle state, or execute remediation automatically.

Bottleneck guardrail: fan-out is an execution-priority signal only. A high score never authorizes skipping a RELEASE, MERCHANT, ATTRIBUTION or same-target dependency; it only makes the blocking task more visible for review/escalation.

V36 WIP Limits & Queue Stability

Control how much remediation work can be active at once. V36 keeps existing work running, reserves capacity for P0/P1, limits route-level concurrency and freezes lower-severity admissions while critical bottlenecks remain unresolved. It does not estimate staffing capacity or execute tasks automatically.

Internal WIP policy: 5 active remediation slots globally, maximum 2 active per route, with 2 slots protected for queued P0/P1 when needed. These numbers are queue-stability guardrails, not a headcount model, delivery promise or external SLA.

V37 Queue Admission Forecast & Capacity Guardrails

Preview the queue state after one candidate admission before opening the remediation. V37 projects global WIP, route WIP, remaining free slots and critical P0/P1 reserve. It does not predict hours, staffing productivity, completion dates or execute admission automatically.

Forecast guardrail: this is a deterministic one-admission state transition using the existing WIP policy. It does not infer task duration or team capacity. `ADMIT_AT_LIMIT` means the task is technically admissible but would fill a global or route limit; `CRITICAL_RESERVE_RISK` keeps lower-severity work queued to preserve P0/P1 headroom.

V38 Queue Recovery & Capacity Rebalancing

When the remediation queue is saturated or under critical-reserve pressure, V38 identifies the active slots that deserve review first: dependency blockers, stale active work and lower-severity work occupying protected P0/P1 headroom. It never closes, cancels, preempts or reclassifies a task automatically.

Recovery guardrail: “reviewable slot” means only that an active task deserves lifecycle review. It is not a free slot until evidence supports a recorded transition such as monitoring, resolution or escalation. P0/P1 work is never automatically displaced, and declared dependencies are never bypassed.

V39 Queue Recovery Verification & Safe Re-Admission

Verify that capacity was actually recovered before admitting new remediation work. Capture a checkpoint, perform the evidence-based lifecycle review, then V39 checks whether previously active slots were released through a recorded RESOLVED, MONITORING or ESCALATED event. A lower active count without matching lifecycle evidence is treated as a gap, not recovered capacity.

Checkpoint is browser-local. Capture it before acting on V38 review candidates; then record the actual lifecycle transition in V30 and verify again.

V39 guardrail: it never infers a free slot from disappearance alone. Missing post-checkpoint lifecycle evidence produces RECOVERY_EVIDENCE_GAP and blocks safe readmission. P0/P1 reserve, route WIP limits and declared dependencies remain authoritative.

V40 Safe Re-Admission Ledger & Capacity Proof

Turn a V39 RECOVERY_VERIFIED result into a bounded, single-use capacity proof. Each manual re-admission consumes exactly one verified recovery unit, so a released slot cannot be counted twice. A commit records authorization only; it does not open, close or execute a remediation automatically.

If AUDIT_DB and the private token are configured, proof creation and commits also enter the existing tamper-evident D1 audit chain.

V40 guardrail: proof units equal confirmed V39 slot releases. A proof from another checkpoint or release is stale; the same task cannot consume the same proof twice; exhausted proof capacity blocks additional re-admission. P0/P1 reserve and dependencies remain authoritative.

V41 Readmission Commit Reconciliation & Orphan Control

Prove that every V40 readmission commit actually becomes a V30 lifecycle activation. V41 links a commit only to a post-commit REMEDIATION_OPENED or REMEDIATION_REOPENED event for the same task. Older lifecycle history never satisfies the commit.

24 hours is an internal orphan-review threshold, not an external SLA. A commit is never treated as activated merely because WIP later changes.

V41 guardrail: voiding an orphan is explicit and append-only. The original V40 proof unit remains retired, so it cannot be silently reused. If capacity still exists, capture a fresh V39 checkpoint and create a new proof. No new Cloudflare binding is required.

V42 Final Production Health & Structural Freeze

V42 closes structural development. Run one authenticated deep health check after deployment to verify the current release identity, critical asset hashes and the operational integrations that support measurement and audit. The health check is read-only: it does not create transactions, experiments, remediation tasks or traffic changes.

Production Freeze is structural, not commercial: continue measuring traffic, clicks, Awin approvals and controlled experiments. Reopen architecture only for a trigger listed in production-freeze-v42.json.

V42 guardrail: ACTION_REQUIRED blocks the freeze until the critical defect is resolved. READY_CORE means the website and affiliate capture are production-safe while one or more optional operational integrations are intentionally unavailable. READY_FULL means all configured checks passed.

V29 Traffic Allocation Guardrail

Use realized Awin economics to decide where additional exposure deserves a controlled test. V29 does not assign paid budgets, does not combine currencies, and does not change links or traffic automatically. A current verified release must also pass the Release Impact guardrail before any page can receive a HIGH/MEDIUM scale recommendation.

Page exposure allocation

Merchant coverage allocation

Allocation guardrail: HIGH/MEDIUM means “eligible for one controlled exposure test,” not “guaranteed winner.” Pages with declining traffic move to RECOVER; high-click zero-result groups move to FIX; current-release negative association, immature release history, mixed currencies or incomplete Awin coverage block scaling.

V29 Optimization Queue

Turn economic recommendations into controlled, reversible tests. V29 defines the hypothesis, one change dimension, primary metric, minimum evidence threshold, review window and guardrail. It never edits production pages automatically.

Experiment discipline: do not change traffic source, CTA wording, placement and merchant offer simultaneously. Winners require downstream transaction evidence; extra clicks alone are not a conversion win. “Control / protect” rows are intentionally left unchanged.

V29 Experiment Lifecycle

Freeze the pre-change economics before touching production, then compare the aligned post-change window. Baselines are immutable in the ledger; evaluations are appended as evidence. Outcomes are Keep / Extend / Revert, with Running until the planned review date.

Local ledger works immediately. Optional Cloudflare KV persistence uses the same private admin token and the EXPERIMENT_LEDGER binding.

Start guardrail: Trend Watch must use the same number of days as the experiment review window. Review on or within 3 days after the planned date with the same window length. If evidence is low, currency is mixed, or the period is misaligned, V29 returns Extend rather than forcing a winner.

V29 Production Change Registry & Surgical Rollback

Attach the exact production modification to each frozen experiment before deployment. V29 stores an immutable change manifest and can generate a rollback manifest that reverses only the controlled fragment. It does not restore a whole old page, so unrelated improvements made later are not automatically discarded.

Use assets/aivs_change_manager_v29.py to validate/apply/rollback manifests on an extracted site copy. Cloud persistence reuses the existing private EXPERIMENT_LEDGER KV binding; no new KV namespace is required.

Rollback guardrail: V29 supports only exact-fragment replacement. A rollback is refused if the experiment fragment is missing, duplicated unexpectedly or has been modified by later work. In that case, resolve the conflict manually instead of overwriting newer changes.

V29 Deployment Identity & Post-Deploy Verification

Verify the exact package that is online before linking a production change to an experiment. V29 checks the stamped release fingerprint, hashes critical deployed assets, and can match the fingerprint to a recent Cloudflare Pages production deployment ID when the optional Pages Read API token is configured.

Package verification works from the deployed fingerprint + probe hashes. Exact Cloudflare deployment-ID matching additionally uses CF_PAGES_READ_TOKEN, CF_PAGES_PROJECT_NAME and the existing CF_ACCOUNT_ID.

Experiment guardrail: “Mark deployed” now refuses unless the online release fingerprint contains that experiment's exact change-manifest hash. This prevents associating a result with the wrong package.

V29 Deployment Audit Trail

Reconstruct the complete production history as an append-only chain: verified release, experiment start, registered change, verified deployment, saved outcome and rollback completion. Each event is chained to the previous SHA-256 hash; a separate D1 head hash makes tail deletion detectable.

The audit endpoint is private and uses the existing AIVS_EXPORT_TOKEN. D1 stores operational metadata only; no visitor click-level identifiers are added to this audit table.

Integrity guardrail: V29 exposes no audit update/delete endpoint. If an event payload, sequence, previous hash, stored head or event count no longer matches, chain verification fails instead of silently accepting the history.

V29 Release Impact Attribution

Associate each verified deployment with the affiliate clicks observed while that release was active, then join Awin transactions by the winning click time. This is release-level association, not proof that the deployment caused the change: seasonality, advertiser changes, promotions and traffic mix can still move results.

V29 excludes transaction click-times within a 3-hour deployment-boundary buffer to reduce timezone/boundary misattribution. Release-tagged clicks are preferred; older untagged clicks use the verified audit timeline as a fallback.

Causality guardrail: V29 never labels a release as the cause of revenue movement. “Positive/negative association” means the measured economics moved during that release window after attribution and sample guardrails; experiment-level Keep/Extend/Revert remains the stronger tool for an individual controlled change.

V29 Release Health & Revenue Guardrails

Check that the release identity, verification probes, click telemetry and audit checkpoint are healthy before interpreting revenue. The economic gate then uses only the real Awin transactions loaded in this browser.

V29 blocks scale on an identity/probe failure or a guarded negative economic association. Missing data produces Hold, not a guessed conclusion.

Action rule: CONTROLLED_SCALE is only advisory. V29 never edits CTAs, increases traffic, deploys or rolls back automatically.

Page-level decision table

How to read the output

V42 production resources

• Deployment fingerprint V42
• Production Freeze policy V42
• Production health rules V42
• Rollback readiness V42
• Production change manifest V42
• Final production runbook V42
• Validated affiliate inventory V42
• Awin advertiser map V42
• Conversion opportunity baseline V42
• Final production validation V42