The Launch Spec: Writing a GA4 Setup Plan a Developer Can Implement Without Guessing

Marketing Academy · Field Work●Analytics & Attribution

MiniBuild the Asset· 30 minutes

Klaviyo

Objective: Write a complete GA4 setup spec, covering event names, key events, and custom dimensions, that a developer could implement without asking you a single clarifying question.

Klaviyo's marketing team is launching a new interactive pricing page next sprint, and you own the analytics requirements doc before a single line of tracking code gets written.

Turn the lesson's 8-step playbook into a concrete, page-specific setup spec: which key events, which custom dimensions, which event names.

Before you start

What you'll need

Free path (everything below is enough to finish)

Google Analytics 4

FreeConfirm the Custom Definitions registration flow

Free, the exact screen a developer will need to use post-launch

Google Sheets

FreeDraft the tracking spec's three tabs

Free, easy to hand off and comment on with a developer

The process

3 steps

Step 01 of 03

Standard event names

The lesson's reserved-names table lists the exact event names GA4's reports and Google Ads integration expect.

The pricing page has a 'Start free trial' button and a 'Talk to sales' button. Which reserved names apply, and which need a custom name?

Google Sheets— New tab in the tracking spec titled 'Event Names'

Procedure

List every trackable action on the page
Match each to a reserved name from the lesson's table where one exists
Flag anything with no reserved match for a custom name

Sample output

EVENT NAMES
  Start free trial click -> sign_up (reserved)
  Talk to sales click -> generate_lead (reserved)
  Pricing toggle (monthly/annual) -> pricing_toggle (custom, no reserved match)

Healthy

Every action with a reserved-name match uses it; only genuinely novel actions get custom names.

Unhealthy

A developer invents 'trial_started' for a signup because nobody told them 'sign_up' already exists and does more.

What this means

The spec is the only thing standing between a developer's best guess and GA4's actual reserved vocabulary.

So what do I do about it?

Symptom	Action	Effort
The spec doc has no 'Event Names' section	Add one before handoff; it's the single highest-leverage page in the doc	5 min

YouYou can do this yourself, no engineering access required.

Step 02 of 03

Key events selection

Step 6 says key events are the specific actions marked as mattering to the business, not just every event that fires.

Of 'sign_up', 'generate_lead', and 'pricing_toggle', which actually deserve key-event status?

Google Sheets— Same spec doc, 'Key Events' tab

Procedure

Review the full event list from Step 1
Mark only the actions that represent real business value as key events
Leave interaction-only events (like a toggle) unmarked

Sample output

KEY EVENTS
  sign_up -> YES, mark as key event
  generate_lead -> YES, mark as key event
  pricing_toggle -> NO, engagement signal only

Healthy

Two key events marked; toggle interaction stays a regular event that doesn't inflate the key-event count.

Unhealthy

All three get marked as key events, and 'pricing_toggle' firing on every hover makes the conversion rate look inflated and meaningless.

What this means

Marking too many events as 'key' is functionally the same mistake as marking none: it stops the metric from meaning anything specific.

So what do I do about it?

Symptom	Action	Effort
More than 2-3 key events on a single page	Re-review the list and demote anything that isn't a direct business outcome	5 min

YouYou can do this yourself, no engineering access required.

Step 03 of 03

Custom dimension registration

Step 7 warns that any custom parameter is invisible in reports until it's registered as a Custom Dimension.

The 'pricing_toggle' event needs a 'plan_type' parameter (monthly vs annual). What has to happen before that shows up in a report?

Google Analytics 4— Admin > Custom Definitions > Custom Dimensions

Procedure

Add 'plan_type' to the spec as an event parameter
Note it in the spec as requiring Custom Dimension registration post-launch
List the exact registration step for the developer/analyst

Sample output

CUSTOM DIMENSIONS TO REGISTER POST-LAUNCH
  Parameter: plan_type   Scope: Event   Registers under: Admin > Custom Definitions

Healthy

The spec explicitly calls out registration as a required post-launch step, so it doesn't get forgotten.

Unhealthy

plan_type gets sent correctly in the event, but nobody registers it, and it shows '(not set)' in every report for weeks.

What this means

Sending a parameter and registering it as a reportable dimension are two separate steps. Skipping the second one wastes the first.

So what do I do about it?

Symptom	Action	Effort
A custom parameter shows '(not set)' in reports	Register it in Admin > Custom Definitions; it will only backfill going forward, not retroactively	5 min

YouYou can do this yourself, no engineering access required.

Final deliverable

A one-page GA4 tracking spec (event names, key events, custom dimensions to register) ready to hand to a developer.

See a reference example

Sample output

Squarespace pricing-page tracking spec (excerpt)

EVENT NAMES
  Start free trial -> sign_up
  Compare plans click -> select_content

KEY EVENTS
  sign_up (marked)

CUSTOM DIMENSIONS TO REGISTER
  plan_tier (Event scope)

Success criteria

You're done when you can:

Maps every trackable action to a reserved name where one exists
Marks only genuine business-outcome events as key events
Explicitly calls out every custom parameter that needs Custom Dimension registration