How to Measure ROI on AI Visibility Without Mixing Denominators

'Blog asset-path attributed' is the only label this protocol permits. It describes a session, signup, or payment where the account record carries a stored reference to the specific blog URL path that preceded it - nothing more. It does not mean the visitor read the page because an AI system cited it, and it does not mean the AI system caused the conversion. Reserve the causal label for a controlled test with a comparison group; this protocol produces a correlation record, tied to your own systems, not a causal one.

Set one time window for the whole calculation and hold it fixed: a 30-day, 60-day, or 90-day trailing window measured from first blog touch, not from calendar month. A calendar-month cut splits a single visitor's journey across two reporting periods and forces you to either double-count the session or drop the record entirely. Pick the window based on your own sales cycle - pull your last closed-won deals from the CRM and check the median days from first recorded touch to close - and write the window into the protocol document so nobody changes it mid-quarter to make a rate look better.

If you do not know your sales cycle length yet, start with a 90-day trailing window and revisit the choice after your first five closed-won deals.

RFC 9309: Robots Exclusion Protocol states: "The User-Agent Line Crawlers set their own name, which is called a product token, to find relevant groups."

Consolidate around one canonical asset path per piece of content instead of fragmenting it across five tracking parameters. One asset_path value that survives from first blog touch to signup to payment reduces the number of joins you have to audit later. Fragmenting it into utm_source, utm_campaign, and a separate CRM lead-source field gives you three fields that can disagree with each other, and no reliable way to tell which one is correct when a deal closes three months later.

Keep the asset_path field alive from blog to billing by capturing the canonical URL path once at first touch and joining every later signup and billing event to that stored value instead of overwriting it.

Blog sessions rose. When finance asked for the confirmed first-paid number tied to that content, marketing could not produce one. The teardown found the root cause: the field meant to carry the blog's contribution forward was never built to hold it.

A visitor who landed on the blog post in week one and converted after clicking a retargeting ad in week three showed up in the CRM as 'paid social' rather than 'blog'. The blog visit was real. The asset_path was captured correctly at the first touch. No dashboard bug caused this. The CRM's single lead_source field was overwritten at every subsequent touch, so by the time the deal closed, the blog's contribution had been silently replaced.

The structural fix is a separate, immutable asset_path field captured once at first blog touch and never overwritten. If your CRM supports custom fields, add one named blog_asset_path_first_touch and set it to write-once: populate it on the first blog-attributed signup event and block any subsequent marketing automation from updating it.

If your CRM's default field behavior lets any workflow overwrite a contact property - check the field-permission settings before assuming otherwise - use a workaround: write the first-touch value to a field your marketing automation workflows are not permitted to update, or store it in a separate data warehouse table keyed to account ID and joined at reporting time rather than at the CRM record level. The warehouse join is the more reliable of the two, because it never depends on every future workflow author remembering the rule.

When the CRM cannot hold a new field at all, store the first-touch value in a separate warehouse table keyed to account ID and treat the CRM lead-source field as last-touch only.

The following numbers are a labeled hypothetical to illustrate the calculation procedure. Do not treat them as benchmarks.

Start with the visit stage. In one fixed 60-day trailing window, your server logs record 460 blog sessions. In this hypothetical, 60 of those sessions carry an automated-agent marker in the stored user-agent field, so 400 qualifying blog sessions remain - the visit denominator. Of those 400, 80 sessions have asset_path stored, so the blog asset-path attributed visit share for the window is 80 divided by 400, or one in five.

Next, the signup stage. The 80 attributed visits become the only denominator for this stage. Of those 80, 3 accounts complete a signup with asset_path present on the account record, so the blog asset-path attributed signup rate is 3 divided by 80.

Finally, the first-paid stage. The 3 attributed signups become the only denominator for the last rate. If 1 of those 3 signups later produces a confirmed first-paid event inside the window plus the payment-lag allowance, the blog asset-path attributed first-paid rate for that cohort is 1 divided by 3 - and a denominator of 3 sits far below the reporting threshold this protocol sets later, so that number stays in the working file and out of the revenue deck.

Neither number tells you what would have happened without the blog content. It tells you what the recorded path was for the accounts that had one.

Mixing a numerator from one evidence class with a denominator from another - for example, dividing 1 first-paid event by 400 total sessions - produces a number that cannot be audited back to a record and will not survive a finance review.

Present the three rates side by side, with their denominators visible, every time you report to a revenue owner. A single percentage without its denominator invites the question 'attributed out of what?' and you want that question answered on the same slide, not in a follow-up meeting. Label the metric 'blog asset-path attributed' in every chart title and every column header - never 'AI-attributed' - because the record you built traces a URL path through your own systems, and your systems record no events inside an AI provider's answer surface.

Stop reporting a rate once its denominator is small enough that one deal swings the percentage by several points. A first-paid rate calculated on a single-digit denominator is not a trend; it is a handful of individual deals. Set a minimum denominator threshold in your protocol document - a reasonable starting point is 20 blog asset-path attributed visits before reporting a signup rate, and 10 blog asset-path attributed signups before reporting a first-paid rate - and hold to it even when a revenue owner asks for the number early.

This protocol traces the URL path your own systems record, never anything inside an AI provider's answer surface. Before you count AI-referred sessions in any denominator, read the primary source below and compare its guidance with what your own server logs show.

The /llms.txt file, v2 - llms-txt states: "Agents are best served by concise, expert-level information gathered in a single, accessible location."