Measurement Setup: Goals, Events, and Conversion Definitions

Why consistent measurement definitions matter

If two campaigns report “conversions” but one counts email signups and the other counts purchases, you can’t compare performance fairly. A measurement setup turns business goals into precise, repeatable rules: which actions are tracked, which actions count as conversions, and how those conversions are attributed and deduplicated. The goal is consistency across channels (paid search, paid social, email, affiliates) and across campaigns (brand vs non-brand, prospecting vs retargeting).

Primary vs secondary conversions

Primary conversions (the KPI you optimize for)

Primary conversions are the actions that most directly represent business value and are used for core reporting and optimization. You typically choose one primary conversion per objective (or per funnel stage) so teams don’t “optimize” toward different outcomes.

• Ecommerce: Purchase (completed order)
• SaaS: Paid subscription start
• B2B: Qualified lead (e.g., lead form submitted and accepted by sales rules)

Secondary conversions (supporting signals)

Secondary conversions are important but not the main optimization target. They help diagnose funnel health, explain changes in primary conversions, and guide experimentation.

• Ecommerce: Add-to-cart, begin checkout, account creation
• SaaS: Trial start, product activation event, pricing page view
• B2B: Content download, webinar registration, chat started

Rule of thumb: If a metric can be “gamed” without creating real value (e.g., collecting low-intent signups), keep it secondary unless your business model truly values that action.

Micro-conversions vs macro-conversions

Micro- and macro-conversions describe where an action sits in the customer journey.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Micro-conversions (intent and progress)

Micro-conversions indicate engagement or intent. They happen more frequently and are useful for early optimization, especially when macro-conversions are rare or have long cycles.

• Add-to-cart
• Signup (newsletter or account)
• Start checkout
• Request demo click (if not the actual submission)

Macro-conversions (business outcomes)

Macro-conversions represent the outcome you ultimately want and usually tie to revenue or pipeline.

• Purchase
• Paid subscription
• Demo request submitted (if it creates a sales opportunity)
• Contract signed (often tracked in CRM rather than on-site)

Common pitfall: Treating a micro-conversion as if it were a macro-conversion in channel comparisons. For example, comparing “signups” from one channel to “purchases” from another will mislead budget decisions.

Event naming conventions and event properties

Events are the raw building blocks of measurement. Conversions are usually defined from one or more events plus rules. A clean event taxonomy makes reporting scalable and reduces ambiguity.

Event naming conventions

Pick a convention and apply it everywhere. Two practical options:

• Verb_noun (recommended): view_product, add_to_cart, begin_checkout, submit_lead_form, purchase
• Object_action: product_view, cart_add, checkout_begin

Guidelines:

• Use lowercase and underscores for readability: submit_lead_form not SubmitLeadForm.
• Use one event name per user action; avoid mixing multiple actions into one event.
• Avoid channel-specific names like google_purchase; channel belongs in properties.
• Define a small set of “core” events used across the business (e.g., purchase, generate_lead) and keep edge cases as additional properties.

Event properties (parameters) to make results comparable

Properties describe context: where the user came from, which campaign, which creative, and what was purchased. For channel and campaign comparability, standardize acquisition properties:

• source: who sent the traffic (e.g., google, facebook, newsletter, partner_site)
• medium: the type of traffic (e.g., cpc, paid_social, email, affiliate, organic)
• campaign: the campaign identifier (e.g., spring_sale_2026)
• content: creative/ad/content variant (e.g., video_15s_variant_b)
• term: keyword or targeting term (often for paid search; can also store audience/targeting label if consistent)

Also standardize business properties for key events:

• Ecommerce purchase: order_id, value, currency, items (or item_count), coupon, shipping, tax
• Lead form submission: form_id, form_name, lead_type (e.g., demo, contact), company_size (if captured), industry (if captured)

Comparability tip: Use controlled vocabularies. For example, decide whether medium is paid_social or social_paid and enforce it. Small inconsistencies create “split rows” in reports.

Step-by-step checklist: document conversion rules

Use this checklist to create a conversion definition that is unambiguous, auditable, and consistent across channels.

1) Name the conversion and classify it

• Conversion name: clear and specific (e.g., purchase_completed, lead_form_submitted)
• Type: primary or secondary
• Level: micro or macro

2) Specify the triggering event(s)

• Which event name triggers the conversion? (e.g., purchase)
• Are there required properties? (e.g., value must be > 0, currency must be present)
• Is it a single event or a sequence? (e.g., begin_checkout then purchase)

3) Define “what counts” (inclusion rules)

• Valid environments only (exclude staging/test domains).
• Exclude internal traffic (employees, agencies) if applicable.
• Define minimum criteria (e.g., purchase must have a valid order_id).
• For leads: define required fields or validation (e.g., business email required, phone optional).

4) Define “what does not count” (exclusion rules)

• Test orders, QA transactions, sandbox payments.
• Duplicate submissions (double-clicks, refreshes).
• Fraudulent orders/leads if you have a flag (e.g., is_fraud=true).
• For B2B: spam leads, personal email domains (if you choose to exclude them).

5) Set the time window

• Conversion window: how long after the click/view you will credit a conversion (varies by channel and business cycle).
• Session vs user window: does the conversion have to happen in the same session, or can it happen later?
• Lead-to-qualified window (B2B): if you define a “qualified lead” conversion, specify how long you wait for qualification (e.g., within 14 days of submission).

6) Deduping rules (avoid double counting)

Deduping is essential when the same conversion can be recorded multiple times (browser + server, multiple pixels, refreshes, CRM imports).

• Deduping key: choose a unique identifier (e.g., order_id for purchases; lead_id or hashed email + timestamp for leads).
• Deduping scope: dedupe within a user, within a session, or globally across all events.
• Multi-system dedupe: if both client-side and server-side send purchase, define which source is authoritative or how duplicates are merged.

7) Value and currency rules

• Revenue: gross vs net (before/after discounts, shipping, tax).
• Currency: store currency and define reporting currency conversion rules if needed.
• Lead value: if you assign values to leads, document the model (fixed value, tiered by company_size, or later replaced by actual pipeline).

8) Refunds, cancellations, and returns

Decide whether you report conversions as “placed orders” or “kept orders.” Both can be useful, but they must be labeled clearly.

• Refund handling: subtract refunded revenue, and decide whether to also subtract the conversion count (often you keep the count but adjust revenue; or you maintain a separate metric like net_purchases).
• Cancellations: define when an order is considered final (e.g., after fulfillment, after 24 hours, after payment capture).
• Subscriptions: define whether conversion is trial start, paid start, or payment success; define how chargebacks are handled.

9) Ownership, change control, and versioning

• Owner: who approves changes to conversion definitions?
• Effective date: when does a new definition start?
• Version: keep a simple version label (e.g., purchase_v1, purchase_v2) and document what changed.

10) Document the definition in a standard template

Mini exercise: write two conversion definitions

Instructions: Use the template below. Write your definition in complete sentences so someone else could implement it without asking follow-up questions.

Template (copy/paste)

Conversion name:  Primary/Secondary:  Micro/Macro:  Trigger event(s):  Required properties:  Inclusion rules (what counts):  Exclusion rules (what does not count):  Time window:  Deduping rules:  Value rules:  Refund/cancellation rules (if relevant):  Notes (edge cases, ownership, version):

Exercise A: Ecommerce purchase conversion definition

Scenario: You run an online store. Users can place orders with card or wallet payments. Sometimes users refresh the confirmation page. Refunds happen within 14 days.

• Define the conversion using a purchase event.
• Specify the deduping key and how you handle refreshes.
• State whether you report gross or net revenue.
• Decide how refunds affect conversion count and revenue.

Example answer (use as a reference, not a rule):

Conversion name: purchase_completed  Primary/Secondary: Primary  Micro/Macro: Macro  Trigger event(s): purchase  Required properties: order_id (string), value (number), currency (string)  Inclusion rules (what counts): purchase event fired on production domain after payment authorization; value > 0; order_id is not null  Exclusion rules (what does not count): events from staging/test domains; internal traffic; orders flagged as test_order=true  Time window: conversion can occur in any session; reporting uses a 30-day post-click window for campaign comparisons  Deduping rules: count 1 conversion per unique order_id globally; ignore subsequent purchase events with the same order_id (e.g., page refresh)  Value rules: net revenue after discounts; exclude tax and shipping; store coupon code when present  Refund/cancellation rules (if relevant): if refunded within 14 days, subtract refunded amount from revenue; keep purchase count as placed-order metric and also maintain a separate net_purchases metric that excludes fully refunded orders  Notes (edge cases, ownership, version): owner=Analytics; version=v1.0; effective date=2026-02-01

Exercise B: B2B lead form conversion definition

Scenario: You have a “Request a Demo” form. Some users submit multiple times. Sales reviews leads and marks them as qualified or disqualified within 7 days. You want comparable reporting across channels.

• Decide whether the primary conversion is form submitted or qualified lead.
• Define deduping (e.g., one lead per company per 30 days, or one per email per 14 days).
• Specify how you exclude spam and internal submissions.
• Define the time window for qualification if you choose qualified lead.

Example answer (use as a reference, not a rule):

Conversion name: demo_request_qualified  Primary/Secondary: Primary  Micro/Macro: Macro  Trigger event(s): submit_lead_form (on-site) AND lead_status_updated (CRM)  Required properties: form_id, lead_id (or crm_lead_id), email_hash, source, medium, campaign  Inclusion rules (what counts): lead form submitted on production domain; business email required; lead is marked Qualified by sales within 7 days of submission  Exclusion rules (what does not count): internal domains; known spam patterns; leads marked Disqualified; duplicate submissions from same email_hash within 14 days  Time window: qualification must occur within 7 days of submission; campaign reporting uses 60-day post-click window due to longer sales cycle  Deduping rules: one qualified conversion per unique crm_lead_id; if multiple submissions map to the same crm_lead_id, count once  Value rules: assign value=0 at capture; later replace with pipeline value when opportunity is created (separate metric)  Refund/cancellation rules (if relevant): not applicable  Notes (edge cases, ownership, version): owner=RevOps + Analytics; version=v1.0; effective date=2026-02-01