Half-day working session

Measurement plan session

A measurement plan is not a catalogue of every tap. It is an agreement about the few moments in the product that the company is willing to read every week, named in a way an engineer can implement and a product lead can recognise six months later.

People seated around a table during a working discussion

Who it is for

Teams about to add tracking to a new flow, or teams whose event list has grown by nickname and never been agreed in one room.

What you receive

A one-product measurement plan: journeys, event names, required parameters, and owners, written down in language both product and engineering can use.

Scope

One product, up to three journeys, in a half-day session (three hours) plus a written plan delivered within five working days.

Who should be in the room

Someone who can decide what the company needs to know, and someone who can say whether a given event is expensive or fragile to implement. Marketing can attend if they read the same property. We will stop the session from becoming a wish list of fifty events.

What the plan looks like

For each journey: the user action, the event name, when it should fire (after success, not on button draw), required parameters, and who owns a change if the screen moves. Malay-language labels for internal reading can be included if the team works in Malay; event names themselves stay in the convention your SDK already uses.

Included

  • Preparation call to collect current event names and screens
  • Three-hour facilitated session (video, or in Penang if the team can gather)
  • Draft measurement plan with event names, parameters, and trigger points
  • One round of written comments

Not included

  • Implementing the plan in the app
  • Auditing whether current events already match the new plan (that is a separate audit)
  • Training a whole company in analytics theory

How the work proceeds

  1. Collect

    We take the current event list, screenshots of the journeys, and the questions the weekly reading is supposed to answer.

  2. Session

    We walk each journey on a shared screen and write the event at the moment the user does the thing, not at the moment a button is drawn.

  3. Plan

    You receive a written plan. One comment round is included.

Preparation

Screenshots or a build, a current event export if you have one, and the three questions you wish the numbers could answer.

Constraints

The session does not inspect whether events currently fire. It agrees what should fire. Pair it with an audit if you need both.