Schema Pulse Point

Flagship engagement

Event Schema Planning

We sit with the people who know the product and write the event dictionary before anyone adds another tracker call. The document is the deliverable. Your engineers instrument from it; we do not ship a product of our own.

Planner spreading paper notes and a printed inventory across a wooden table
Duration
Three to six weeks
Where it happens
On-site sessions in Kuala Lumpur, with remote writing days between visits
Fees
Quoted from the event inventory. Most first plans land between RM 18,000 and RM 45,000.

Who it is for

Product managers, analytics leads, and engineering managers who are about to instrument a new app, or who can no longer trust the events already firing.

What you leave with

A versioned tracking plan: every event the product actually needs, the properties each event may carry, identity rules, and a handoff sheet that names the screen, trigger, and payload for each platform.

In scope

  • Inventory of user actions that deserve an event, and a short list of actions that should stay as screens or logs
  • A naming convention the whole company can apply without a meeting
  • Property catalogue with allowed values, types, and cardinality notes
  • Identity model: anonymous, signed-in, and how a session should stitch
  • Versioning rules for when an event changes meaning after a release
  • Handoff tables for iOS, Android, and web, including trigger and payload

Included

  • Two discovery workshops (half day each) with product, analytics, and one engineer per platform
  • A draft dictionary after week two, reviewed in a working session
  • A final tracking plan in a shared document plus a printable property appendix
  • A two-hour handoff with the engineers who will write the tracker calls
  • Thirty days of written questions after delivery, for naming disputes only

Not included

  • Writing production code or pull requests in your repositories
  • Building dashboards, funnels, or board packs
  • Media buying, attribution vendor selection, or campaign tagging
  • Ongoing weekly reporting after the thirty-day question window

How the work proceeds

  1. Read the product, not the tracker

    We walk the current app with a product owner. Every tap that later becomes an event has to correspond to a real step a person takes. We note where the same action has three names across squads.

  2. Write the inventory

    Actions are sorted into events, screens, and things that should never leave the device. High-cardinality fields (search strings, SKUs, free-text) are flagged before they land in a payload.

  3. Lock names and properties

    Object_action names, required properties, optional properties, and forbidden properties are written in one table. Ambiguous labels such as click, submit, or success are replaced with the business action.

  4. Handoff and version stamp

    Engineers receive a sheet per platform. The plan is stamped v1. Changes after release follow the versioning rules in the same document, so last quarter’s funnel still has a name.

Preparation

Send the current event list export if you have one, a product walkthrough account, and the names of the people who will own naming disputes. We do not need admin access to your analytics account.

Constraints

One app per engagement. A second brand, white-label, or a separate merchant app is a second plan. We will not invent events for features that are not in the current or next release.

Next step

Write to us with the app name, the approximate number of screens, and whether you already fire events. We reply with a scoping note and a proposed workshop date.

Write with the app name