What the dashboard is standing on
A dashboard is the last five percent of the work. This is the other ninety five: what gets measured, what each measurement carries with it, and the rule that decides whether it gets built at all.
Same invented company. CambiumPak makes recycled and compostable B2B packaging. Every event name, parameter and number here was written for this demonstration.
The architecture is the real deliverable and it is portable — this is the shape I would build on any site. Only the products are made up.
Those products are published at cambiumpak.com, which is what every event below is designed to measure.
How a click becomes a number someone can act on
five steps · nothing here is a plugin
Step 02 is the one people skip. If the push is ad hoc, every later step inherits the mess, and you find out eighteen months later when someone asks a question the data cannot answer.
Every event is tied to a live business question
if an event cannot name the decision it informs, it does not ship
| Event | The question it answers |
|---|---|
| configurator_start | Does the box configurator get used at all, and by whom? |
| configurator_complete | Do configurations succeed or fail, and at which step do people stop? |
| material_comparepaid tool | Is this subscription worth renewing? |
| rightsize_calculate | Is anyone reaching the calculator we license from a third party? |
| credit_finder_search | Do buyers actually care about recycled-content credits, or do we only think they do? |
| document_download | Which spec sheets and test reports actually drive demand? |
| portal_login | Who uses the distributor portal: internal staff, reps, fulfilment, or brand buyers? |
| form_submit | Which forms convert, and which ones only collect abandonments? |
| sample_request | The conversion that matters. Everything above is a leading indicator of this. |
The segmentation on portal_login is the row worth pausing on. A single login count tells you nothing you can act on. Split by customer type, it tells you the portal is being used mostly by distributor reps, not the brand sustainability leads it was designed for — which is either a repositioning or a redesign, but you cannot know that from a total.
What each event carries
the parameters are where the answers actually live
configurator_complete
- box_style
- mailer · rsc · die-cut · tray
- internal_dims
- bucketed, never raw
- material
- corrugated · molded pulp · compostable film
- recycled_pct
- banded: 0–39 / 40–69 / 70–100
- outcome
- saved · sent_to_rep · abandoned
document_download
- doc_type
- spec · droptest · compostability · recycled_content
- product_sku
- the specific item
- product_family
- so it rolls up without a lookup table
- source_page
- where the download was triggered from
portal_login
- customer_type
- internal · distributor_rep · fulfilment · brand
- account_tier
- the commercial segment
- first_login
- true once, ever — activation, not traffic
form_submit
- form_type
- sample · quote · contact · spec_help
- product_context
- what they were looking at when they asked
- completion_ms
- bucketed — long fills mean a confusing form
product_family is there on purpose. Without it, every roll-up needs a join against a SKU list that nobody maintains, and within a year the reporting quietly stops matching the catalogue.
The governance rules
written down before the first tag, because retrofitting a naming convention is not possible
Events are things a person did. Parameters are the details. If you find yourself writing download_spec_sheet_pdf, you have put a parameter in the event name and you will never be able to total downloads again.
snake_case, verb last or verb first, but pick one. The convention matters less than the fact that there is one.
No personal data, ever, including in parameters. Dimensions get bucketed or banded before they are sent. A raw dimension is a liability with no analytical upside.
Every event names the decision it informs. The table above is not documentation written afterwards. It is the intake form. An event with an empty right-hand column does not get built.
Plan the migration before the relaunch, not after. A relaunch destroys the historical baseline unless the mapping is deliberate. That window closes on launch day and does not reopen.
The dashboard this feeds is here, the step-by-step build is in the process write-up, and the real project it is modelled on is in the analytics case study.