Most GA4 properties fail in one of two ways: they count pageviews that say nothing about intent, or they flood reports with generic click events nobody can read. MME-GA4 replaces both with a fixed, weighted event plan per URL, so the report can say on which page, and at which step of the decision, a reader stopped.
What is the MME-GA4 framework and why does it exist?
The MME-GA4 framework is a deterministic, dual-layer event taxonomy for Google Analytics 4. Macro events are high-intent conversion commitments, such as a submitted form, a call or a chat. Micro events are the incremental behavioural steps that show a reader moving toward that commitment. Every canonical URL is given a Lead Map that pairs one primary macro event with a weighted ladder of micro commitments.
It exists because analytics usually drowns in signal noise: either raw pageviews that carry no intent, or a flood of uncontextualised click events. The specification states its operating axiom as a single chain:
Canonical URL [Lead Map]
--> 1 Primary Macro Event [weight = 1.0]
--> DLN Micro Commitment Ladder [weight 0.1 - 0.6]
--> GA4 and GSC conversion attribution
Read left to right, the chain says the event plan starts from the page, not from the tag manager. A URL without a Lead Map cannot be given a primary macro event, and an event with no URL behind it is noise.
How are GA4 events weighted by decision stage?
GA4 events are weighted by decision stage because, under MME-GA4, events are not created equal. Each event carries an explicit attribution weight from 0.1 to 1.0, set by the commitment it shows and by its stage in Decision Ladder Navigation. The weights allow a lead to be qualified by behaviour before any form is submitted.
| DLN stage | Intent role | Weight | Example GA4 events | Behavioural target |
|---|---|---|---|---|
| Orient (O) | Information and need | 0.1 | scroll_50, click_toc, time_60s | Reading engagement, table-of-contents navigation and initial topic orientation. |
| Choose (C) | Solution comparison | 0.25 | click_spoke_link, view_matrix | Solution exploration, comparison table interactions and category filtering. |
| Prove (P) | Trust verification | 0.4 | view_case_study, expand_proof | Trust verification, proof accordion expansions and case study engagement. |
| Rate (R) | Commercial evaluation | 0.6 | view_pricing, download_spec | Commercial evaluation, pricing views and specification sheet downloads. |
| Act (A) | Primary conversion | 1.0 | submit_form, click_call, click_chat | The primary macro event: direct business lead generation or transaction. |
Only the Act row is a macro event. The four rows above it are micro events: they explain the path to a conversion, and their weights rank how much each step says about purchase intent without ever being counted as a conversion.
Which parameters does every MME-GA4 event carry?
Every MME-GA4 event carries the same five-key parameter schema, attached to every custom event, so that parameters never drift between Google Tag Manager and GA4. Each key has a fixed vocabulary; a value outside it is a tracking defect, not a new category.
page_type: the architectural role of the current URL, for example pillar, spoke, landing or entity.link_zone: the visual DOM region where the interaction happened, for example top_menu, main_menu, body, sidebar or footer.cta_position: the exact spatial placement, for example above_fold, mid_body, bottom_sticky or sidebar_card.cta_target: the exact conversion destination, for example contact_form, phone_call, zalo_chat or booking_calendar.intent_stage: the decision stage of the interaction: orient, choose, prove, rate or act.
How does Section Isolation keep GTM triggers precise?
Section Isolation keeps GTM triggers precise by stopping secondary sections, such as footer links or sidebar advertisements, from polluting the primary lead metrics of a page. MME-GA4 enforces it in Google Tag Manager with three rules, each of which can be verified in GTM Preview mode.
- Element ID and CSS scope locking: triggers bind to specific container IDs, for example
#primary-content a.cta-btn, rather than to global tag names. - De-duplication governance: a macro event fires exactly once per pageview; a micro event such as a scroll threshold is throttled to once per element.
- Normalised dataLayer events: every push is a structured object using the standard event names and parameter values, for example
dataLayer.push({'event': 'submit_form', 'cta_target': 'contact_form', 'intent_stage': 'act'}).
What does the 20-point MME-GA4 audit check?
The 20-point MME-GA4 audit checks technical compliance across five domains of four checkpoints each. Every checkpoint is binary and names the tool that verifies it, so two auditors reach the same result on the same site. The five domains follow the order in which a tracking plan is built.
| Domain | Checkpoints | Verification |
|---|---|---|
| 1. Macro events | CHK-01: lock one primary macro event per canonical URL. CHK-02: the macro event fires only on successful form validation. CHK-03: click_call and click_chat fire with the correct tel: or chat href. CHK-04: macro events are marked as Key Events in GA4. | URL Lead Map audit, GTM debug and console, DOM inspection, GA4 Admin settings. |
| 2. Micro events | CHK-05: map micro events to the O, C, P and R stages. CHK-06: assign attribution weights of 0.1 to 0.6 in GTM lookup tables. CHK-07: track 50% and 75% scroll depth with a section lock. CHK-08: cap micro event frequency to prevent event flooding. | DLN matrix review, GTM lookup table, GTM scroll trigger, GA4 Realtime inspection. |
| 3. Parameters | CHK-09: page_type on every custom event. CHK-10: link_zone names the DOM region. CHK-11: standardised cta_position and cta_target naming. CHK-12: all five parameters registered as GA4 custom dimensions. | dataLayer object audit, DOM container review, GTM variable audit, GA4 custom definitions. |
| 4. GTM precision | CHK-13: triggers scoped with exact CSS container selectors. CHK-14: no duplicate firing on rapid double-clicks. CHK-15: cross-domain tracking tested on external booking widgets. CHK-16: dataLayer push syntax validated before the GTM container is published. | GTM selector test, click throttle test, GA4 DebugView, GTM Preview mode. |
| 5. Analytics QA | CHK-17: 100% data parity between GTM events and GA4 reports. CHK-18: Search Console query mix aligned with event intent stage. CHK-19: conversion attribution models validated in GA4 Advertising. CHK-20: every tracking change logged in the weekly engineering SOP log. | GA4 Realtime audit, GSC performance export, GA4 attribution panel, SOP change log registry. |
How is the MME-GA4 framework declared to machines?
The MME-GA4 framework is declared to machines through a Schema.org @graph block on every tracking specification page. Under the SP-8 rule, the JSON-LD must keep word-for-word parity with the rendered page text, because a claim that exists only in markup is a claim no reader can check.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebPage",
"@id": "https://danhnolan.com/en/mme-ga4/#webpage",
"url": "https://danhnolan.com/en/mme-ga4/",
"name": "GA4 Micro-Events and Macro-Events Framework (MME-GA4)",
"isPartOf": {"@id": "https://danhnolan.com/#website"},
"about": {"@id": "https://danhnolan.com/en/mme-ga4/#term"}
},
{
"@type": "DefinedTerm",
"@id": "https://danhnolan.com/en/mme-ga4/#term",
"name": "GA4 Micro-Events and Macro-Events Framework (MME-GA4)",
"description": "A deterministic dual-layer event measurement taxonomy mapping Macro Events and Micro Events to URL-level Lead Maps and Decision Ladder Navigation (DLN) stages.",
"inDefinedTermSet": {"@id": "https://danhnolan.com/en/mme-ga4/#termset"}
},
{
"@type": "DefinedTermSet",
"@id": "https://danhnolan.com/en/mme-ga4/#termset",
"name": "MME-GA4 Specification",
"sameAs": "https://doi.org/10.5281/zenodo.22971501"
}
]
}
What does the 30-day MME-GA4 roadmap look like?
The 30-day MME-GA4 roadmap looks like four sprints of roughly a week each, and each sprint ends with an artefact the next one depends on. Building attribution reports before the parameters are standardised only produces a report that has to be rebuilt.
- Sprint 1, days 1 to 7, audit and URL Lead Map blueprinting: audit the top 20 landing pages, define one primary macro event and two or three micro commitments per URL, and build the URL-to-event matrix.
- Sprint 2, days 8 to 15, GTM deployment and parameter standardisation: configure GTM tags, triggers and normalised dataLayer variables for all five parameters.
- Sprint 3, days 16 to 23, GA4 Key Event QA and custom dimensions: verify Key Events on every money page, register the custom dimensions in GA4 Admin and test DebugView for full parameter accuracy.
- Sprint 4, days 24 to 30, conversion attribution and weekly SOP loop: inspect GA4 attribution models, cross-reference the Search Console query mix with event intent stages and set up the seven-day review cycle.
How does the 100-point Definition of Done score?
The 100-point Definition of Done scores a tracking implementation across five domains of 20 points each, and the implementation must reach at least 90 out of 100 before it goes to production. A lower score sends the work back to the sprint that owns the failing domain.
| Evaluation domain | Points | Pass criteria |
|---|---|---|
| 1. Macro event isolation | 20 | One primary macro event locked per canonical URL; it fires only on a valid conversion. |
| 2. Micro event progression | 20 | Micro events mapped to the O, C, P and R stages with weights of 0.1 to 0.6 and throttle limits active. |
| 3. Parameter governance | 20 | page_type, link_zone, cta_position, cta_target and intent_stage populated on 100% of events. |
| 4. GTM and DOM integrity | 20 | Triggers scoped to container IDs; no duplicate fires; cross-domain widgets verified. |
| 5. Analytics and attribution QA | 20 | GA4 Key Events active; Search Console query mix aligned; Schema @graph keeps 100% parity with the page. |
What do readers ask most often about MME-GA4?
These are the questions readers ask most often about the GA4 Micro-Events and Macro-Events Framework. Each one is answered directly from the specification, in a few sentences, so that the answer can be read, quoted and cited on its own without the rest of this page.
What is the difference between a micro event and a macro event in GA4?
A macro event is a high-intent conversion commitment, such as a submitted form, a call or a chat, and is marked as a GA4 Key Event with a weight of 1.0. A micro event is an incremental step, such as reading to 50 percent or opening pricing, that shows the reader moving toward that commitment. Micro events carry weights between 0.1 and 0.6.
How many macro events should one URL have?
Exactly one primary macro event per canonical URL. Checkpoint CHK-01 locks it, and CHK-02 requires it to fire only on a successful form validation, so the conversion count cannot be inflated by ghost submissions. Secondary actions on the same page are tracked as micro events, not as a second macro event.
Should micro events be marked as GA4 Key Events?
No. Only macro events are marked as Key Events. Micro events stay as ordinary events with a weight between 0.1 and 0.6, held in a GTM lookup table under CHK-06, and are throttled under CHK-08 so they explain the path to a conversion without flooding the property.
Is MME-GA4 an official Google Analytics standard?
No. MME-GA4 is an independent specification written by Danh Nolan for use with Google Analytics 4 and Google Tag Manager. It is not a Google product, not an official GA4 feature and not part of the GA4 Measurement Protocol. It uses only standard GA4 and GTM features, so it runs on any property without extra software.
How can the MME-GA4 specification be reused and cited?
The MME-GA4 specification can be reused under the Creative Commons Attribution 4.0 International licence. You may copy, redistribute, adapt and build on the material for any purpose, including commercially, provided you give appropriate credit, link to the licence and indicate whether changes were made.
Cite this specification as: Nolan, D. (2026). GA4 Micro-Events and Macro-Events Framework (MME-GA4): A Deterministic Event Taxonomy, URL-Level Lead Mapping, Behavioral Qualification, and Conversion Attribution Standard for AI Search Optimization. Technical Working Paper, danhnolan.com Research Group. Zenodo. 10.5281/zenodo.22971501. All versions: 10.5281/zenodo.22971500. ORCID: 0009-0007-7906-5091. Deposited 26 September 2026 under CC BY 4.0.
The deposit is the authoritative version. Where this page and the deposited document differ, the deposited document under the DOI is correct, because that is the version other people cite and the version that carries a fixed date.