Domain 2 of 6

Instrumenting a Product

Where the numbers come from. Events and their properties, the tracking plan that keeps a taxonomy readable as a team grows, how one person is recognised across devices and sessions, what consent law allows a product to collect and what refusing it does to the figures, and the data quality failures that quietly invalidate everything downstream.

Concepts

~12%

Of the exam

Practice questions

Concepts in this domain

01Events and propertiesThe event model a product analytics practice is built on, the three kinds of property and why the difference between them decides what a team can ask later, an object action naming convention, and the choice between many specific events and few general ones carrying properties.02The tracking planThe document that holds every event a product records, the columns each row carries, the review a proposed event goes through, how a plan is versioned and how an event is retired, and why a plan that exists only inside the analytics tool has no owner at all.03Identity and sessionsHow an analytics tool decides that two events came from one person, what stitching an anonymous identifier to a known account can and cannot recover, the browser storage limits that make a returning visitor look new, and the session as a timeout rule that changes every measure counted per visit.04Privacy and consent in analyticsWhich facts inside an event property count as personal data, the lawful basis and the four tests a consent has to pass, how long a record may be kept, and the arithmetic showing what a declined consent rate does to every funnel and cohort the product reports.05Data quality in analyticsThe six failures that quietly stop collected data matching what happened, from an event that never fires to a field renamed in a release, the checks that catch each one, reconciliation against a system of record, and the honest way to report a loss that cannot be recovered.

Try a question from this domain

A food delivery product records an event called Order Placed and attaches nothing to it. The team wants to know whether orders paid by saved card are cancelled less often than orders paid at the door. What does it need?

AA second event called Order Paid, fired at the moment the payment is taken.
BProperties on the event that already exists, since an event answers when and how often and properties answer for whom, of what kind and how much.
CA user property holding each customer's usual payment method, which can then be applied across their orders.
DOne event per payment method, so the two populations can be counted straight against each other.

11 questions on this domain.

One per page, with a worked explanation.

Start the set