Capability template for analytics and reporting
Tracking event plan
Before analytics goes onto a website or app, the founder or product owner gets one plan: the events and properties worth collecting, when each fires, where it goes, what it is called and who owns it, each tied to a question the business needs answered. The owner approves what is collected.
Listed under
Add it to a workflow in the Fully Powered Planner, beside the teams and roles that will run it. Book a fit call
The outcome
You start measuring with a plan instead of a guess. Before anyone adds a line of tracking, you hold a short list of the things the site or app should record, and next to each one the question it will help you answer. If nothing you want to know needs a thing, it is not on the list.
Each event comes with a plain statement of the moment it fires and the moments that do not count, so a developer cannot reasonably read it two ways. Each carries only the details your questions need, a name that follows one rule, the places the data goes and the person who owns what it means.
The plan is honest about its edges. A question the plan cannot answer, because the answer lives somewhere else, is listed with what is missing. A detail that would identify a person, or that sits on your own never-collect list, is held for you and never slipped in. You decide what is collected. The plan writes no tracking code and gives no advice about privacy rules or consent notices.
Who starts the work, and when
The founder, product owner or marketing lead starts it before a website or app is instrumented, when a new feature or step needs measuring, or when an old tracking setup has grown names nobody trusts. That person brings the questions and the description of the journey, and reviews the result with whoever will build it.
The owner approves what is collected. The person who builds it confirms the plan can be built as written.
What they supply
- The questions the business wants answered, in its own words, each with the decision it will inform.
- The journey: the steps a visitor or user takes, where each happens and what the site or app does in response.
- The events already collected, if any, with a name, a description and a destination each.
- The destinations: the tools the data goes to, what each is for and who owns it.
- The settings: who approves, who owns meaning, who builds, a naming rule if the business has one, and anything that must never be collected.
What comes out
One dated plan, in a fixed order: each question with the measure that answers it, or the reason it cannot be answered yet; each event with when it fires, when it does not, its properties, its destinations, its owner and how to check it once built; existing events that were not reused and why; fields held for the owner and fields on the journey that are not collected; and a numbered list of decisions for the owner. Nothing is built, switched on or sent.
An invented example
Illustrative example with invented data. The company, the tools and the people below are all invented. Studio L is an invented 12-person workshop that makes furniture to order and takes quote requests through its website. Its two tools are called Tool A (analytics) and Tool B (email service). The founder is about to have a contractor add tracking to the site. First come the inputs the founder supplied, in full, then the plan the capability returned.
The inputs
1. Settings (typed by the founder)
Business: Studio L
Today: Tuesday 10 November 2026
Workflow: the Studio L website
Runner: Founder
Approver: Founder
Event owner (who says what an event means): Founder
Builder: Web developer (contractor)
Naming rule: default
Never collect: names, email addresses, phone numbers, anything typed into the message box
2. Questions (typed by the founder)
id,question,decision it informs,asked by
Q1,"What share of people who look at a piece go on to ask for a quote?","Whether the autumn budget goes to the product pages or to advertising",Founder
Q2,"Which kinds of project do quote requests ask about?","Which three pieces to photograph for the spring catalogue",Founder
Q3,"Which quote requests become orders?","Whether to follow up every request within a day",Founder
Q4,"How many people join the newsletter, and from which kind of page?","Whether to keep the sign-up box in the footer",Founder
Q5,"Do people like the new homepage?",,Founder
Q6,"How many people ask for a quote more than once?","Whether to merge repeat requests in the office",Founder
3. The journey (typed by the founder)
step,where,what the visitor does,what the site does
1,"Home page and range pages","Arrives and browses the ranges","Shows the three ranges: dining tables, desks, shelving"
2,"Product page","Opens a piece","Shows photos, sizes and a from-price"
3,"Quote form page","Presses Ask for a quote, then fills in name, email, project type (dining table, desk, shelving or other), budget range and a message, and presses Send","Shows Thank you, we reply in two working days, and emails the form to the office"
4,"Footer of every page","Types an email address and presses Subscribe","Shows You are subscribed once Tool B has accepted the address"
4. Events already collected
event_name,description,destination
page_view,"Any page opens",Tool A
quote_submit,"Quote form sent",Tool A
signup,"A visitor joined something",Tool A
5. Destinations
destination,used for,owner
Tool A,"Counting visits and actions on the website",Founder
Tool B,"Sending the newsletter",Office manager
The plan
TRACKING EVENT PLAN: the Studio L website
For: Founder. Prepared Tuesday 10 November 2026, from 6 questions, 4 journey steps, 3 existing events and 2 destinations. Naming rule: default (object, then action in the past tense, lowercase, words joined by underscores). Destinations: Tool A, Tool B. Counts: Questions 6 (answered 3, not answerable 1, need rewording 1, held 1). Events 3 (1 new, 2 existing reused with a change, 0 existing reused unchanged). Properties 2, each counted once (page_type on 2 events, project_type on 1). Decisions 8.
Questions
- Q1. What share of people who look at a piece go on to ask for a quote? Decision it informs: whether the autumn budget goes to the product pages or to advertising. Measure: visitors, as Tool A counts them, who sent at least one quote request, out of visitors, as Tool A counts them, who opened at least one product page, in the same period. Answered by: page_view with page_type product; quote_submit. The plan adds no way to recognise a visitor and relies on Tool A's own count. See decision 7.
- Q2. Which kinds of project do quote requests ask about? Decision it informs: which three pieces to photograph for the spring catalogue. Measure: quote requests sent, counted by project type. Answered by: quote_submit with project_type.
- Q3. Which quote requests become orders? Decision it informs: whether to follow up every request within a day. Not answerable from this plan: the sale happens outside the website. The plan can count requests but cannot show which became orders; that needs a link between a request and the order book. See decision 5.
- Q4. How many people join the newsletter, and from which kind of page? Decision it informs: whether to keep the sign-up box in the footer. Measure: subscriptions completed, counted by the kind of page the visitor was on. Answered by: newsletter_subscribed with page_type.
- Q5. Do people like the new homepage? Decision it informs: no decision named. Needs rewording: "like" is not something a site can count, and no decision depends on the answer. No event is planned for it. See decision 6.
- Q6. How many people ask for a quote more than once? Decision it informs: whether to merge repeat requests in the office. Held: the decision is to merge repeat requests in the office, which needs individual requests tied to one person, not a count of visitors from Tool A, and the only candidates on the form are on the never-collect list. The plan proposes none. See decision 8.
Events
page_view (existing, reused; change: add one property)
- Moment: step 1 and step 2, and every other page.
- Fires when: any page opens, as it does now. Does not fire when: not stated for this existing event; the builder confirms it fires once per page opened and says how a reload is handled today.
- Answers: Q1.
- Properties: page_type, the kind of page opened. Values: home, range, product, quote, other (other added by the plan). Required: yes. Needed by Q1.
- Goes to: Tool A. Owner: Founder. Built by: Web developer.
- Check once built: open a product page; Tool A shows one page_view with page_type product. Open the home page; one page_view with page_type home.
quote_submit (existing, reused; change: add one property)
- Moment: step 3.
- Fires when: the trigger is unchanged; the builder confirms it fires once per quote form sent. Does not fire when: not stated for this existing event; the builder confirms that an attempt that shows an error, a second press of Send on the same form and a reload of the Thank you message add nothing.
- Answers: Q1, Q2.
- Properties: project_type, the project type the visitor chose on the form. Values: dining_table, desk, shelving, other. Required: yes. Needed by Q2.
- Goes to: Tool A. Owner: Founder. Built by: Web developer.
- Check once built: send a test request choosing desk; Tool A shows one quote_submit with project_type desk. Make the form show an error, in a way the builder describes; no event appears. Reload the Thank you page; nothing more appears.
newsletter_subscribed (new)
- Moment: step 4.
- Fires when: the You are subscribed message appears. Does not fire when: Subscribe is pressed but Tool B does not accept the address, Subscribe is pressed a second time on the same message, or the message is shown again on reload.
- Answers: Q4.
- Properties: page_type, the kind of page the visitor was on, with the same values as on page_view. Required: yes. Needed by Q4.
- Goes to: Tool A. Owner: Founder. Built by: Web developer.
- Check once built: subscribe from a product page with a test address of your own; Tool A shows one newsletter_subscribed with page_type product. Reload the page; nothing more appears. Press Subscribe with an address Tool B will not accept, which the builder can tell you how to supply; nothing appears.
Similar names and existing events not reused
- signup (Tool A): not reused. Its description, "A visitor joined something", could cover the newsletter or something else, so the plan cannot tell whether it is the same action as newsletter_subscribed. See decision 4.
Existing names that break the rule
- page_view (Tool A): the rule would give page_viewed. Kept, not renamed. See decision 2.
- quote_submit (Tool A): the rule would give quote_submitted. Kept, not renamed. See decision 3.
Existing events left as they are: signup, which is listed above as not reused. They are left as they are.
Held for the owner
- A way to tie individual requests to one person, for Q6: none proposed. See decision 8.
Not collected
- Name, email address, message (quote form): on the never-collect list.
- Budget range (quote form): no question needs it.
- Email address (newsletter box): on the never-collect list.
Coverage: every event serves at least one question. Questions with an answer in this plan: Q1, Q2, Q4. Questions without: Q3 (not answerable), Q5 (needs rewording), Q6 (held).
Destinations: Tool A receives page_view, quote_submit and newsletter_subscribed; owner Founder. Tool B receives no event from this plan; what Tool B stores is outside it.
Decisions for the Founder: 8
- Approve what is collected: three events (page_view, quote_submit, newsletter_subscribed) and two properties (page_type, project_type), including the added property on each of the two existing events, and the page_type value other, which the plan added because the journey names only four kinds of page. Nothing else is collected.
- page_view does not follow the naming rule; the rule would give page_viewed. It is kept and not renamed. The plan does not know how Tool A treats a renamed event or whether history is joined. Say whether it stays as it is.
- quote_submit does not follow the naming rule; the rule would give quote_submitted. It is kept and not renamed, with the same unknown about Tool A. Say whether it stays as it is.
- signup is not reused. Say what fires it today. The plan does not change it.
- Q3 is not answerable from this plan. Say whether the answer is to be found elsewhere, such as in the order book. Not planned here.
- Q5 needs rewording and names no decision. Reword it as something a site can count, with the decision it informs, or drop it.
- Q1 relies on Tool A's own count of visitors, which the plan neither adds to nor changes. Say whether that count is good enough for the budget decision. The builder can say how Tool A counts the same visitor across a product page and a later quote request.
- Q6 is held. Say whether any way of tying individual requests to one person is to be considered. None is proposed.
Not supplied: nothing missing. The plan has not seen how Tool A counts visitors, which Q1 depends on; that is a setting in Tool A. No list of page kinds was supplied, so the page_type values come from the journey, plus other.
Draft for the Founder's approval. Nothing has been built, switched on or sent.
Where it fits
- Analytics and reporting, where measurement definitions are written down before they are built.
- Product management, where a new feature needs a way to tell whether it worked.
- Software and technology, where a product team adds events to every release.
- Ecommerce and retail, where the path from product page to order is the thing to measure.
- Professional services, where a firm's website exists to bring in enquiries.
- Startups & new ventures, where the first analytics set-up shapes every report that follows.
- New business lines, where a new offer needs its own measures from day one.
It is a different piece of work from website findability audit, which looks at whether search engines can reach and read your pages, and from lead magnet plan, which plans a free resource. Here the website or app already exists or is about to, and the question is what it should record.
What has to change for your company
Write your own questions and the decision behind each; the plan is only as sharp as they are. Set your naming rule once and keep it. List the destinations you actually use and who owns each. Decide what must never be collected and put it in the settings, so it is held every time. Agree who approves and who builds. Give the plan to the person who will build the events, and have them confirm each trigger before work starts.
What has been checked
Fully Powered AI wrote this capability template. It was editorially reviewed on 10 November 2026. It was tried on its invented example by Claude on 10 November 2026 (the second recorded run, which replaced a first); the record is in the trial. It has not yet been tested in a client environment, or as a packaged version in ChatGPT, Claude, Copilot or Gemini.
Testing in your environment means running it on a journey you know well, with cases written in advance: a question with no decision, an existing event whose name is close to a new one, a question that needs a personal detail. The owner and the builder read every trigger before anything is built.
The full capability template
Everything above is the outline. The complete capability template is the working version: the roles, the inputs, the procedure, the exceptions and stop conditions, the output format, the reviewer checklist, the acceptance tests, the instructions for an AI assistant and what to customize for your company. It comes with a download and the link to its folder in Fully Powered’s public repository.
Free with an account. Sign in by email: no password and no card.
Next step
Put this capability to work for your team: on your plan, or built with you in a sprint.
Build this in a sprint
In a sprint, Fully Powered adapts this capability template to your rules, proves it on your own work and puts it in the hands of the roles that own it.
Two ways to begin: