- What should a Saudi business measure in GA4 to support a decision?
- How can event contracts distinguish website activity from commercial progress?
Begin with the meeting decision
A GA4 implementation can collect many interactions while leaving a Saudi business unable to answer a simple question: which website journeys generate enquiries that sales can actually use? The solution is not automatically more events. It is a measurement plan that connects each business question to an observable action and an accountable decision.
Before discussing tags, ask marketing, sales, product, and the implementation owner to nominate the decisions they need to make. Prioritize a small set. An event without a foreseeable use can create maintenance work without improving judgment.
Translate questions into an event contract
Use one row per meaningful action, with these fields:
- Business question and decision owner.
- Observable action and exact trigger condition.
- Event name and whether an existing recommended event fits.
- Required parameters and their permitted values.
- Collection method, implementation owner, and test evidence.
- Reporting destination and known interpretation limits.
Google distinguishes automatically collected, enhanced measurement, recommended, and custom events in its GA4 event guidance. Check existing collection before adding another tag. Where a recommended event matches the action, review its documented definition and parameters rather than inventing a near-duplicate name.
Treat naming conventions as an internal governance choice, within Google's technical requirements. Prefer stable action names over labels tied to a temporary page design. Document parameters separately so developers do not guess what a value means.
Complete an unfilled enquiry-event specification
Use columns for the business question, observable action, confirmed success condition, event definition, allowed parameters and responsible reviewer. Leave observations blank until both language journeys are tested. Identify an enquiry submission through its confirmed success state, not simply a click on the submit button.
Check whether the recommended generate_lead definition fits the documented action before choosing an event name. Keep service category, page language and form identifier separate from personal data. Names, emails, phone numbers and free-text messages should not be inserted into analytics payloads.
Review the Arabic and English implementations against the same meaning of completion. Record validation failure, repeated clicks and return paths so differing layouts do not silently change the count. Connect later sales qualification through a separately governed process rather than treating GA4 submissions as proof of lead quality. The specification should show which decision each event supports and what the measurement cannot establish.
Approve a minimum useful taxonomy
A compact first release is easier to validate than a catalogue of every visible interaction. Include an event only when the team can explain what it observes and which decision changes when its pattern changes.
For each proposed event, run an acceptance scenario: perform the action once, confirm the event appears, inspect required parameters, and verify it does not fire for a failed or unrelated action. Test refreshes, back navigation, and single-page transitions where relevant. Record the expected result and evidence, not just a checked box.
Changes to the form, booking system, or website language routing should trigger a targeted retest. Assign someone to approve definition changes before they reach production.
Avoid confusing activity with commercial progress
Common mistakes include recording a button click as a completed enquiry, giving the same action different names across languages, and marking every interaction as commercially important. Another is declaring implementation complete without an owner who reviews whether reports answer the original questions.
For downstream decisions, connect this plan to CRM sales outcomes. Discuss collection controls alongside consent-aware analytics, rather than treating technical configuration as legal compliance.
Ask Kitely to facilitate a measurement workshop that produces an approved question register, event contract, and bilingual acceptance checklist before implementation begins.
