Meaning
What are we actually counting?
A booking click, a confirmed reservation and a fulfilled visit describe different outcomes. The definition determines what a report can tell us.
Crown Resorts / Measurement
Connect the business question to the work that answers it.
At Crown Resorts, I connect stakeholder needs, measurement design and agency delivery. I define what a measure means, make the work clear for specialists, and challenge whether the reporting answers the original question.
Explore the work
- Scope
- Website, member journeys and external booking measurement.
- My role
- Measurement design, requirements, agency briefing and reporting review.
- Delivery
- Agency partners undertake substantial technical implementation. The framework remains in development.
01 / The challenge
Agree what matters.
Keep it clear through delivery.
A stakeholder asks a business question. An agency needs a technical specification. A developer needs an implementation brief. The report at the end still needs to answer the question that started the work.
Ownership
What does each team need to deliver?
Existing tracking, replacement collection and new coverage need different scopes. A shared project still needs explicit handoffs.
Confidence
Does the report support that conclusion?
Grouping, event order and missing context can change the interpretation. A reported implementation change needs evidence before acceptance.
02 / What I did
Define the answer
before the event.
I authored a connected reference that carries a stakeholder question through its measure, collection requirements, reporting and acceptance. Shared definitions and naming rules give the individual specifications a common foundation.
Give each measure a purpose
I specify the counting unit, period, denominator and exclusions before deciding what to collect. For a booking question, that includes separating when a reservation is made from when the visit takes place.
Give specialists a shared reference
The reference connects events, required fields, data-layer sources, tag mappings and checks. Existing definitions can be reused; proposed changes have a place to be recorded and reviewed.
My role is to connect the business meaning with the technical requirements, so that each implementation can be checked against its purpose.
03 / Delivery leadership
Make the scope clear
for the people doing the work.
I consolidated related stakeholder requests into one agency brief. I separated three kinds of work: review existing tracking, replace fragile collection and design missing coverage. Each has its own deliverables and checks, under one shared set of rules.
- Agree the needStakeholder + agency
The question, the measure and the required answer.
- Specify and implementAgency to developer
The agency defines the data layer; the developer implements it.
- Collect and validateAgency
Tracking configuration, test evidence and reporting checks.
The immediate assignment stays simple. Technical detail sits alongside it, ready when someone needs to implement or review the work.
Explore the example agency briefThree scopes, clear owners and inspectable deliverables
Example agency briefSynthetic content / design demonstration
The job in one sentence
Agree the questions, specify the data layer for the developer, configure and test tracking, then build or update the reporting.
Stakeholder question / Service portal
Which help topics do visitors open?
Help the service team decide which guidance to review first.
- 01
Agency + stakeholder
Agree the answer
Count topic opens by topic key. This measures interest, not whether the guidance solved the problem.
Deliverable: agreed measurement definition - 02
Agency specifies · developer implements
Provide the data layer
After a visitor opens a help topic, publish its stable catalogue key. Exclude the visitor’s search text.
Deliverable: event, fields, trigger and example payload - 03
Agency
Configure and test tracking
Read the agreed data layer through Google Tag Manager and map the event and fields into analytics. Opening a topic produces one event with its key. Simply viewing the list produces none.
Deliverable: configuration and observed test evidence - 04
Agency + stakeholder
Build or update reporting
Topic opens by topic key and date. Label the count as opens, not unique people or resolved enquiries.
Deliverable: report checked against the original question
Inspect the illustrative data contract
What the developer receives
The final contract needs field types, permitted values, when to send the event and the expected checks. This small specimen shows the shape of that handoff.
- Event
select_content- Fields
- content_type, item_id. All values shown here are example strings.
- Acceptance
- Opening a topic produces one event with its key. Simply viewing the list produces none.
Synthetic payload / not a production specification
{
"event": "select_content",
"content_type": "help_topic",
"item_id": "example_topic_a"
}Shared rules: reuse before adding
Check the existing catalogue
Look for an event that already describes the same action. Compare its meaning, trigger and fields before proposing another event.
Keep one naming standard
Use approved event names, field names, types and value lists. Record any required extension in the shared reference before implementation.
Collect only what answers the question
Define the purpose and permitted data for each field. Exclude personal details, credentials and unrestricted text. Agree retention for temporary keys.
Make acceptance observable
Specify expected events, negative checks and duplicate handling. Keep implementation evidence separate from a design being ready.
These are example briefing rules. Explore the wider measurement framework for the connected reference design.
My contribution is the requirements, scope, briefing structure and review criteria. Delivery partners implement their agreed scope. This demonstration does not claim that the example has been deployed or that it reduced cost or delivery time.
04 / Judgement in review
Check the interpretation
as well as the implementation.
My contribution continues after the specification. These two delivery reviews show how I question reporting logic and define what needs to be checked before accepting a change.
Reporting logic
Keep the journey’s origin
separate from later choices.
During a member-journey dashboard review, I questioned whether grouping each stage by the currently selected location could represent a sequential funnel. A person could enter through one location and select another later.
I asked for the starting location to remain distinct from the current selection, and raised a separate journey key for analysing each selection in sequence.
Reported response
The agency reported using the originating analytics property as a stable grouping and adding a separate view of location switching. It used existing grouping information rather than adding the proposed journey key.
Inspect the grouping example
Reconstructed example / generic locations
- Group by current selection
- Entry: Location A
Next stage: Location B
Successive stages can fall into different groups. - Keep origin and selection separate
- Entry: Origin A · Selection A
Next stage: Origin A · Selection B
Origin remains stable; changes can be analysed separately.
Stable grouping alone does not prove correct event order or counting. Analysing each selection as its own sequence remained a separate requirement.
Implementation acceptance
Carry the starting context
through the booking.
In a booking-documentation review, I asked for a reference that explained sequence, branching and data at every step without requiring the reader to open tracking tools.
In a separate kiosk booking QA request, I specified that the starting surface should remain identifiable through an embedded vendor journey. I asked for completion, repeat events and unrelated activity to be checked.
Reported response
The agency reported adding an origin parameter. Acceptance still requires evidence that the complete journey preserves that context and meets the agreed checks.
Inspect the acceptance checks
Adapted proposed checks / not test results
- Start on the designated surface and complete an authorised test booking.
- Verify that the starting surface survives the vendor handoff and confirmed outcome.
- Repeat an action, revisit confirmation and enter through another surface. Check duplicates and unintended inclusion.
- Review the dated event sequence, payloads, destination mapping and report definition. Record untested paths.
These examples are adapted from my requests and the agency’s written responses. They establish the review and reported revisions, rather than independent validation of the final implementation.
05 / Results and contribution
A shared design.
A clear basis for review.
The work produced a connected measurement reference and practical agency briefs. The delivery examples also show requirements I raised and changes the agency reported making in response.
What I contributed
I authored the framework, consolidated requirements, scoped agency work, challenged reporting definitions and specified review criteria. The value of that role is keeping business meaning, technical delivery and interpretation connected.
What the evidence supports
This case demonstrates design and delivery leadership. Agency partners contribute implementation, configuration, reporting and technical QA. The framework remains in development; production acceptance and a measured business uplift are not established here.
A related challenge?
Start with the problem.
Make the next step useful.
For conversations about measurement, applied AI and digital experiences that help people act.
Start a conversation