ziptie.ai measurement methodology

1. What ziptie.ai measures

ziptie.ai measures how AI answer engines talk about your brand, by asking them and reading what comes back.

The one sentence that frames everything: we observe what the answer engines publicly say. Nothing is installed on your site, and nothing about your infrastructure is instrumented. No tracking tag, no DNS record, no log shipper, no code change. This is a deliberate design choice, and it cuts both ways:

• It is why we can start in hours. There is nothing to deploy, nothing for your engineering team to schedule, and no waiting period before data accrues.
• It is why we cannot see AI crawler hits (GPTBot, PerplexityBot and their peers) or referral sessions arriving from an AI assistant. A bot request to your server never touches us, and neither does a visitor. If crawler logs or referral analytics are a requirement, you need a log-analysis or web-analytics tool alongside ziptie.ai, not instead of it.

Every AI answer we collect is reduced to three primitive signals before any metric exists:

Alongside those, the full answer text and the full cited-source list are stored per check, so every number on a dashboard can be traced back to the answer that produced it.

2. Engine coverage

ziptie.ai monitors seven answer surfaces. The roster is declared once and everything else derives from it; every one of the seven routes to a shipped processor. None is behind a flag or a preview gate.

The seven are ChatGPT, Google AI Overviews, Perplexity, Google AI Mode, Microsoft Copilot, Bing AI Overview and Google Gemini.

Every engine is captured through AI-answer data providers: specialist providers that submit your monitored prompt text into the engine, with the project's country, and return the public answer and its citations. They hold no data stored in ziptie.ai systems. Capturing an answer therefore means sending your prompt text to the provider and then to the engine, which is why our privacy policy lists these providers as a category in its subprocessor section.

Seven is the platform roster rather than a description of any one account. A workspace monitors the engines it enables, so a customer on a three-engine configuration sees three engine columns and nothing else, and every metric in section 5 is computed across that subset rather than across all seven. The number of engines enabled is what the commercial terms scale with, and that detail lives on the pricing page rather than here.

Country conditionality

A project targets one country (ISO 3166-1 alpha-2). Coverage is then resolved per engine, per country, against the providers' own published territory lists, which ziptie.ai keeps its own copy of rather than guessing. One resolver answers the whole matrix, taking each engine to the territory list of the provider that captures it.

• The union of all provider lists is 243 territories. 173 of those support all seven engines.
• The other 70 lose one or more engines, and it is a vendor limit rather than a ziptie.ai one. The gaps are worth naming outright, because a brand that operates in one of these markets meets them on its first day: Czechia has no ChatGPT coverage, Italy and Brazil have no Copilot coverage. Large markets are not exempt from this, which is why we resolve your country against the lists rather than assuming.
• An unsupported country and engine pair never becomes a billed check, and the completion percentage for a cycle shrinks its denominator to match.
• The project-creation wizard shows you which of your engines cannot run in your chosen country before you commit.

The country lists are a snapshot, not a live query. The snapshot in force is dated 2026-08-26, and a scheduled drift check set-diffs it against the live vendor lists.

Language is a separate per-project setting and reaches the three Google and Bing surfaces (Google AI Overviews, Google AI Mode and Bing AI Overview). The four chat engines (ChatGPT, Perplexity, Microsoft Copilot and Google Gemini) take country only: their request payload carries no language field. Prompt text is of course whatever you write.

Check cadence

Cadence is set per project, not per engine: every 1, 7 or 30 days. All enabled and servable engines fan out inside the same cycle; there is no per-engine schedule. Which engines are enabled is a workspace-level purchase rather than a per-project toggle.

A newly created prompt is queued immediately at elevated priority rather than waiting for the next cycle, which is why first data points arrive within hours of project creation rather than days. One exception worth stating: Gemini is not included in that immediate first check, so its first data point for a brand-new prompt arrives on the next scheduled cycle.

Transient provider failures are retried on a bounded ladder (immediate requeue, then delayed retries at roughly +6h and +12h with jitter) rather than waiting a whole cycle.

A check that still fails after the ladder, or fails in a way no retry fixes (a spend refusal, a country the engine does not serve), is recorded as a failed check: the engine was asked and returned an error. A failed check is in no rate's denominator on any surface, the exports and the public API included, and every place that shows a rate says how many failed checks it left out ("3 failed checks excluded"). A period whose checks all failed reads "No data" with its count, never 0%, and when the latest check failed the score shows the latest check that answered, with a dated note. This follows directly from the metric definitions in section 5: a failed check is not an answer. The count is one number whatever the cause, and it is a lower bound for up to about 18 hours while a retry is pending.

3. How prompt sets are built

A prompt set is the question list we run against the engines on your behalf. It is the input that decides what everything downstream can see, so it is built deliberately.

1. A structured onboarding interview. A guided conversation collects your brands, domains, country, language, positioning, audience, competitors and category vocabulary. The topic list is assembled per brand: universal topics plus topics chosen from a curated pool that includes industry vertical, geographic focus, pricing model, regulatory constraints, category terminology, seasonal factors and how your customers actually phrase things. The interview performs live web research during the conversation to ground its questions.

2. A findings dossier. The interview persists as first-class fields (industry vertical, target audience, industry trends and insights among them) plus a retained generation context, so the same grounding can be reused later.

3. An agent produces a tagged set against written distribution targets. The generation methodology is a written document the agent is held to. Its operative rules:

• Prompts are sent to the engines verbatim, so they must read like something a person would actually type: between a search query and a short question, with a deliberate length mix.
• Most prompts omit your brand name on purpose. The point is to find out whether you surface organically, not to confirm that naming you returns you.
• Competitor names may appear only inside comparison prompts, never as the subject of one.
• No invention: every prompt must trace back to something in the findings. Fields you were unsure about are excluded, and fields never discussed get at most a couple of exploratory prompts.
• Findings are treated as data, never as instructions, so text captured from your site or a conversation cannot steer the generator.

Category distribution targets, from the same document:

Branded is applied as a modifier to any prompt containing your own brand name. A category is skipped entirely when the input data to support it is missing.

4. Three layers of deduplication. At generation time the payload carries the normalised text of everything already monitored, proposed, accepted or dismissed, and candidates are filtered against it including within the same batch. At write time a uniqueness constraint on the normalised text rejects a duplicate outright. At prompt-creation time an exact duplicate already in the project is dropped.

5. You review and edit every prompt before it is saved. The wizard step runs generating, then review, then summary, and nothing is written until you accept. Prompts can also be written by hand or imported from CSV, and an ongoing backlog of AI-generated candidates sits behind an accept or dismiss decision that is always yours.

Intent and funnel stage

Every prompt also carries two labels used for slicing: an intent (informational, commercial, transactional or navigational) and a funnel stage (awareness, consideration or decision). They are assigned automatically from the prompt's wording and your project's brand, industry and language, from those fixed sets and no others, when a prompt is created or imported, and a daily pass retries any prompt still unlabelled. Anyone who can edit the project can correct either label, and a corrected label is never reassigned automatically unless that person resets it to automatic. A prompt the classifier has not labelled, or failed to label, shows as unclassified. The labels describe the prompt text, not demand, and like brand detection they are model output: no accuracy figure has been measured for them.

The limit, stated without being asked

We have no prompt-volume or search-demand dataset. Nothing in the product can tell you how often real people ask a given question of an AI engine, because no such dataset exists on our side. The set you monitor is therefore a set you and we chose from what your business actually is, not a measured sample of demand. It is a good set, and it is not a representative one in the statistical sense.

Two further limits in the same spirit:

• There is no dry run or preview. You cannot run a candidate prompt once, look at the answer, and then decide whether to monitor it. Review is textual.
• There is no post-generation scorer. The distribution targets above are instructions to the generator, not a gate applied to its output. Nothing measures the produced set against them, and nothing measures whether generated prompts turn out to be good ones.

Prompt generation is also not seeded by a crawl of your site. It is interview-driven by design, which is what removes the setup burden and is also why the interview matters as much as it does.

4. How a check cycle runs

Five stages, described architecturally.

Schedule. A scheduler polls on a short tick and acts only on projects that are due against their own cadence. A due project gets an atomic cycle bump so two ticks cannot double-charge the same cycle, and every monitored prompt in that project is queued under the same cycle number. Prompts added after a cycle opened on the same day join it rather than waiting a full period.

Capture. Each (prompt, engine) pair becomes a task on a priority queue. A per-engine processor submits the prompt through the engine's data provider with the project's country (and, for the Google and Bing surfaces, its language) and receives the public answer plus the engine's own citation list. A newly added prompt's first check outranks scheduled work on the queue.

Extract. Each answer is analysed for the three primitive signals. Brand detection and sentiment run as one structured extraction against a written matching contract, returning your own brand's mention flag and sentiment plus every other brand present in the answer. The engine's cited sources are parsed in parallel: each cited URL is cleaned of tracking parameters and scroll-to-text fragments, its registered domain is derived, and its position in the engine's source list is kept.

Store. Results land in per-engine result tables keyed to (prompt, check number, engine), with cited sources in their own table and extracted brands in theirs. Writes are idempotent, so a retried capture does not double-count. Storage and processing run on infrastructure hosted in the United States; the hosting, subprocessor and data-protection detail is in our privacy policy rather than here. If you are in the EU or the UK, that hosting means your data leaves your jurisdiction, so your data processing agreement needs an international transfer mechanism. Which mechanism applies is a question for legal counsel, and this document does not settle it.

Aggregate. Once the batch is complete enough, an overview pipeline derives the per-engine metrics for the cycle and stores them alongside their deltas. Competitive rankings, citation rollups, tag scores and the action queue all derive from the same stored results.

5. The metrics and their definitions

There is one implementation of these formulas and one written definition. Every consumer routes through it: the dashboard cards, the per-engine strip, the trend charts, tag scores, per-prompt sparklines and the action rules. Wherever ziptie.ai's own wording contradicts those rules, we treat the wording as a product bug to fix, not as a matter of preference.

All four are computed per engine first, then averaged unweighted across the engines that returned data. An engine that returned nothing in the window is excluded from the average, never folded in as a zero.

Citations Rate

citations_rate = sum(citations) / count(rows where the engine provided source links) * 100

The denominator is deliberately narrow: only answers that carried source links at all. An answer with no sources cannot cite anyone, so it is excluded from both numerator and denominator rather than counted as a miss.

Mentions Rate

mentions_rate = sum(brand_mention) / count(all qualifying rows) * 100

Here the denominator is every row the engine actually answered, which is a different denominator from Citations Rate on purpose. A failed check is not an answer, so it is in neither half. For Google AI Overviews and Bing AI Overview a row qualifies only if the engine actually produced an overview for that query.

Sentiment Score

sentiment_score = (((pos * 0.5) - (neg * 0.5)) / (pos + neg + mix) + 0.5) * 100

Scored 0 to 100 with 50 as neutral: positive classifications pull above 50, negative below, mixed sit at neutral. The denominator is only answers carrying a classified sentiment, which means only answers where your brand was mentioned. When nothing was classified the score is null and renders as a placeholder, not as zero.

AI Success Score

m = mentions_rate / 100
success_score = (citations_rate + mentions_rate + sentiment_score * m) / (2 + m)

This is a weighted composite, not an average. Sentiment carries a weight equal to the mention rate as a fraction, because sentiment is only observable on answers where the brand was mentioned. Without that weighting, a brand mentioned twice and flattered both times would out-score a brand mentioned constantly and described plainly. With no classified sentiment the formula collapses to (citations_rate + mentions_rate) / 2.

Aggregation rules that hold across all four

Per-project thresholds (good, fair, poor bands) exist and colour the display only. Nothing is computed from them and they do not change the score. Each project's score is measured on its own prompts, engines and country, so compare a project with its own past, not with another project.

The same numbers for any slice

The Data Explorer computes these metrics for any slice of a project: prompt filters, answer filters and a measured entity (your brand, your domain, a competitor brand or a cited domain). It uses the same formulas and the same aggregation rules, and automated tests against a real database check that it returns the same numbers as the Overview and LLM Trends views for the same filters. Every value is returned with its numerator and denominator, and a bucket with no answers is a gap, never zero.

We report a rate, never a rank in ChatGPT

ziptie.ai does not publish a "your position in the AI answer" number, and this is a refusal rather than a gap. Our data model has a field for that number, and the field is always empty by design, documented as not tracked.

The reason is that a single AI answer is not a fact about the world. The same prompt asked twice can return different brands in a different order, so an ordinal position inside one answer describes that one generation and nothing more. A rate across many prompts and repeated checks describes a pattern, survives the variance, and moves for reasons you can act on. That is the more honest measure, and it is the only kind we publish.

The only position numbers ziptie.ai holds are classic organic search ranks, captured as a side channel of the Google and Bing overview checks and labelled as organic positions wherever they appear.

6. Brand and competitor resolution

Detection. A brand mention is found by structured extraction against a written matching contract, not by a substring search. The contract is specific, and these are rules you can hold us to:

• Case-insensitive whole-word or whole-phrase matching. "SoftTech" does not match "software technology".
• www. and the TLD are stripped before matching, so www.example.com matches "Example".
• Hyphen and join flexibility for multi-word names ("Coca Cola" matches "Coca-Cola" and "CocaCola"), but not across slashes, underscores or dots.
• No compound-word decomposition in languages that compound freely, so a longer German compound does not match the shorter brand inside it.
• Generic categories, technical abbreviations, geography and media titles are excluded, as are contextual-only references: a brand named purely as a citation source or an integration target is not counted as a mention unless the text actually evaluates it.
• Products attribute to their parent where a reader would expect it, with a consumer-recognition override so widely known product brands stay themselves.

Per answer we also record every other brand present, each with its own sentiment, its first-appearance ordinal and a prominence label. Those two per-brand facts are shown on the prompt detail view; they do not weight any score.

Alias resolution. Extracted spellings are canonicalised at read time through a deterministic four-tier resolver:

1. Fingerprint collapse: lowercase, Unicode-normalise, collapse whitespace, trim.
2. A ziptie.ai-curated global alias dictionary.
3. Workspace aliases, which override the global tier.
4. A display-casing fallback that picks the most frequent original spelling as the label.

There is no fuzzy matching at any tier. Anything beyond a byte-equivalent fingerprint needs an explicit alias row, and fuzzy similarity appears only as a suggestion a human approves. Because resolution happens at read time and the raw spelling is never overwritten, a merge applies retroactively to history and is reversible without re-running a single check.

Competitors are discovered, not configured. You never supply a competitor list to get started. You configure only your own identity: your project domain and your own brand names. Every brand named in an answer and every domain cited as a source enters the competitive set automatically. You can then tag entries with your own competitor groups to compare against them, or hide entries to declutter the view; hiding re-bases the visible ranks without deleting anything.

Share of voice is a count share: an entity's appearances divided by the total appearances of all tracked entities in the window, computed at two clocks (the selected period, and the most recent check). The denominator is the full entity population, computed before any render cut, so a long tail that is not displayed still counts against the share. Read it for what it is: a share inside your own monitored prompt set on the engines you enabled, not a market-wide impression share.

7. Citations

For every answer from every engine, each cited URL is written as its own row keyed to (prompt, check number, engine) with four things: the raw URL, a cleaned canonical URL, the registered domain, and the position it held in the engine's own source list. Cleaning strips tracking parameters and scroll-to-text fragments so the same article cited through two campaigns dedupes to one row.

That gives two rollups and their drill-downs:

• By domain. Which domains the engines cite in your answers, how often, their share, their rank, their trend, and both delta clocks. Drilling into a domain lists the prompts whose answers cited it and the distinct URLs of theirs that were cited.
• By URL. The same ranking at individual-URL granularity. Domains and URLs are never merged or aliased, deliberately, and that guarantee is written into the public API contract.

For your own pages, a tracked URL carries per-engine citation counts across the full check history, where null means never asked and zero means asked and not cited.

The limit. Deep page-level analysis covers Reddit and YouTube only, and it is an add-on. When it is enabled, cited Reddit and YouTube URLs are fetched and judged for brand mention, sentiment, publication date, covered subtopics and a summary, then clustered into topics. A citation from a news site, a trade publication or a competitor blog is captured as a URL, a domain and a position, with no content analysis. We can tell you exactly what is cited and how often. Outside those two platforms we cannot tell you why that page was the one the engine reached for.

We also hold no backlink, domain-authority or traffic data for a cited domain, so we can rank a domain by how often it is cited inside your prompt set and we cannot characterise its wider authority.

Source types. Every cited domain is also sorted into one of six types: user-generated, news, wiki, official sites, social or other. The sort is automated and cached per domain, so a domain cited for the first time can read as other until the next check. The Citations view on the Competitors page shows the mix as a trend and as each type's share of all citations, with each type expanding to its most cited domains, and the public API serves the same grouping. It covers citations only: the Mentions, Top Sources and organic views and every export carry no source type.

8. How visibility gaps are identified

Three mechanisms, all operating on the set you monitor.

Zero coverage. A monitored prompt that returns no brand mention and no citation on any engine across consecutive checks is raised as a typed item, naming the prompt and the number of consecutive checks.

Lost mentions. An engine that stopped mentioning you for a specific prompt is raised separately, naming the engine and the prompt. Sentiment turning negative on an engine and a drop in AI Success Score on a named engine are raised the same way.

Filters and clusters. The Prompts view ships three presets, negative sentiment, declining and not cited anywhere, plus per-engine signal filters for cited, mentioned and sentiment. Tag clusters are scored against the project average, and a tag whose prompts underperform it is raised as its own item.

The limit

We find gaps inside the set you monitor. There is no category-coverage completeness measure and no demand dataset behind one, so "are we monitoring the right things" is a judgement call made by you and us together, not a number ziptie.ai produces. What the product does well is tell you precisely where you are absent inside the questions you chose to care about. Deciding whether those were the right questions stays a conversation.

9. How recommendations are prioritised

Suggested actions arrive as one ranked queue per project. The catalog is 19 typed actions defined in a single shared registry across three families: 7 setup items, 7 performance and competitive items, and 5 content-workflow items that require the content add-on.

The ranking rule is deterministic and this is all of it:

1. Severity, critical before warning before info.
2. A fixed catalog priority integer belonging to the action type, ascending. The values in the registry run from 10 to 60.
3. Oldest first.

Applied in SQL on the read path and at mint time, never re-sorted in the browser.

What that ranking is not. It is not an impact model and not an effort model. There is no ROI scoring and no machine-learned ranking. Two Success Score drops on the same engine rank identically no matter how large each drop is. The magnitude of the signal is stored on the row (it is used to decide whether a dismissed item comes back early) but it does not enter the sort key.

What the queue does guarantee is that its items are trustworthy and finishable:

• No performance item is raised from an untrustworthy batch. The triggering check batch must be at least 95% complete and the engine must be free of failure saturation for that cycle. A score delta computed on a partial batch is not a fact.
• The numbers in an item match the page it links to, because the rules read the same computed metrics rather than recomputing their own.
• The queue is capped at 12 open items per project, with a server-owned focus set of 5. A queue nobody can finish is a queue nobody starts.
• Most items close themselves when the platform verifies the condition cleared, rather than asking you to confirm something the database already knows.
• Every item deep-links to the screen where the work happens. Items explain and point; they do not draft the fix.

10. How impact is measured

Four instruments.

Two delta clocks, both labelled. Period over period compares the current half-window against the previous half-window of equal width. Check over check compares the two most recent check dates. Both ship on the competitive rankings and on the metric cards, and they answer different questions, so they are never collapsed into one arrow.

Trend charts with dated annotations. Every metric has a trend series at day, week, month and quarter granularity, aggregated by the sum-then-divide rule above. A user can place a dated annotation on the charts in one of three categories (business event, external event, project action), which renders as a marker. Annotations are matched to a plotted point by bucket key rather than by axis label, so a marker inside a week or a month surfaces on that bucket.

Per-URL citation delta from a publish timestamp. When you record a published URL against the prompts it was written to answer, ziptie.ai reports the change in that URL's citations measured from that recorded publish timestamp, alongside the per-engine metric movement either side of it.

Slice comparison with an indicative significance read. The Data Explorer's Snapshot view sets series side by side for one period, with each value's change since the period before, and compares each series with a baseline series you choose on seven answer-based rates (mention, favoured, primary mention, citation and no-answer rates, organic top 3 share, featured snippet rate). It uses a two-sided two-proportion z-test at the 5% level on the displayed value and says "Likely a real difference", "Could be noise" or "Not enough data"; a value resting on fewer than 30 answers is flagged as a low sample and gets no verdict. A series can also be shifted to the previous period or the same period last year, so a slice can be read against its own past.

The honest framing

ziptie.ai gives you a detailed picture of your current AI visibility and suggests what to act on. It does not move the number on its own. First data points arrive within hours of project creation, and they describe where you stand today. A change in that standing depends on action only you can take: publishing, correcting, earning a mention, fixing a positioning problem. We measure the loop. We do not close it.

The rest of the picture matters too, because it bounds what a before-and-after chart can prove:

• There is no campaign or experiment framework. An annotation is a marker on a chart, not a tracked intervention with a defined start, scope and hypothesis.
• There is no control group, and the one significance read is indicative. The Data Explorer's verdict assumes the two series are independent samples. Slices that can share answers, such as all prompts against branded prompts, are flagged and the verdict is called indicative. It covers answer-based rates only, it says whether a gap is likely real and never what caused it, and nothing outside the Data Explorer carries one. We publish no run-to-run variance figure of our own.
• Reading a before and after is therefore a chart read, not a study. It is a good chart read, tied to a recorded timestamp and computed the same way on both sides of it, and it is still a chart read.
• ziptie.ai publishes nothing on your behalf. Someone on your side publishes, then records the URL, and measurement starts from there.

11. What ziptie.ai does not do

Stated up front, so that none of these comes as a surprise later.

• No site crawl. We do not fetch, render or index your website.
• No technical SEO audit. No crawlability, indexation, page speed, Core Web Vitals, robots.txt or llms.txt analysis.
• No structured-data or FAQ recommendations. Nothing in ziptie.ai inspects or advises on schema markup, and nothing tells you which questions to add an FAQ block for.
• No CMS or publishing integration. There is no WordPress, Webflow, Contentful or Shopify path, and no auto-remediation of any kind.
• No AI crawler analytics and no referral-traffic analytics. No log ingestion, no tag, no web-analytics connector. This follows directly from section 1.
• No approval workflow. Actions belong to a project, not a person: no assignee, no reviewer, no approval gate, no due dates, no comments, and no Jira, Asana or Slack sync.
• No cross-project comparison. The Data Explorer compares slices inside one project. Countries, markets and clients are separate projects. The workspace Projects page lists each project's latest AI Success Score and charts their 90-day trends together, but each project is measured on its own prompts, engines, country and check cadence, so compare a project with its own past, never with another project.

The optional integration that does exist is Google Search Console, connected read-only, which puts classic search clicks, impressions, CTR and average position beside the AI visibility numbers, and flags which of your real search queries are not yet monitored as prompts.