Most businesses do not have an analytics problem. They have an analytics installation that was completed as a checklist item, three years ago, by someone who was never told which questions it was supposed to answer.
The symptom is familiar: a dashboard someone opens monthly, notices traffic is up or down, and closes. That is not analytics failing. That is analytics doing exactly what it was configured to do, which was nothing in particular.
This article covers the part that gets skipped: the event model underneath the tool, what a real business should actually watch, why your numbers will never match your ad platform, and where the privacy line sits. Warehouses and business intelligence are a different subject, covered in our data analytics and BI guide, and consent is covered in full in our cookie consent guide.
What an event actually is
An event is a specific interaction or occurrence on your website or app, covering page loads, link clicks, purchases, and app crashes [1]. The mental shift worth making early is that a pageview is not a separate thing from an event. In GA4 a page view is one of the events collected automatically [1]. Everything is an event, and pageviews are the least interesting ones you have.
Events come in three kinds, and the distinction decides how much of your reporting works.
Automatically collected events arrive by default when analytics is set up, covering page views, session starts, first visits, outbound clicks, scrolls and file downloads [1]. These are free and they are also why a default installation looks like it is working while telling you nothing.
Recommended events are ones you implement using predefined names and parameters, which Google states unlock existing and future reporting capabilities [2]. There are standard names for the things most businesses care about: a lead generation site has events for generating and qualifying a lead, and a commerce app has events for viewing an item, adding to cart, beginning checkout, purchasing and refunding [2].
Custom events are ones you define, and Google's guidance is unusually blunt: only create them when no other event works for your use case [2].
Most implementations get this backwards. Someone invents a custom event name for a purchase, and in doing so opts out of every built-in report, audience and future feature that would have recognised the standard name. Google's documentation states that data from recommended events automatically updates predefined dimensions and metrics [2]. Use your own name and none of that happens.
Parameters, and the step nearly everyone misses
Parameters are the data carried alongside an event, such as the value and currency on a purchase. They are what makes an event analysable rather than merely countable.
Here is the step that quietly breaks most implementations: parameters are not automatically reportable. They must be registered as a custom dimension or custom metric before you can build reports or explorations around them, and there is roughly a day or two of processing before a newly registered dimension starts populating [4].
Until someone performs that registration, the data is being collected and is invisible. It is one of the most common findings when we open an existing account: the tracking works, the reporting was never finished.
The limits matter too, because they are lower than people assume. Google documents up to 25 parameters per event, event names capped at 40 characters, most parameter values capped at 100 characters, and 25 user properties per property [3]. A standard property allows 50 event-scoped custom dimensions and 25 user-scoped ones [4].
Those ceilings are the practical argument for a measurement plan, and this is our own reasoning rather than something Google states. Because custom events do not populate standard reports on their own, because parameters need explicit registration, and because both have hard limits, an implementation done without deciding in advance what matters produces one of two outcomes. Either a pile of collected-but-unreportable parameters, or the ceilings filled with the wrong things. Writing the business questions first, then mapping each to an event and its parameters, is what keeps an implementation inside the limits and pointed at something reportable.
One more limit worth planning around: event-level data retention on a standard property is configurable at two or fourteen months, with longer windows only on the paid tier, and data is deleted once it ages out [5]. Year-on-year comparison needs somewhere else to keep it.
What a real business should watch
A lead generation site needs three numbers weekly and a transactional app needs four, and everything else is decoration.
Key events are the mechanism. A key event marks an action particularly important to your business, any collected event can be marked as one, and once marked it appears in a dedicated column across standard reports including landing pages and user acquisition [6]. That single step turns an undifferentiated wall of events into a report that answers whether the site is working.
Worth getting the vocabulary right, because it comes up in supplier conversations. A key event is the important action tracked inside Analytics. A conversion is specifically a key event connected into Google Ads for bidding and ad reporting [7]. Google's framing is that aligning the definitions across both platforms lets you see consistent metrics in each [7].
For a lead generation website, three numbers usually suffice: the key event representing a genuine enquiry, fired on a real form submission rather than a thank-you page load; the funnel from landing page to that key event; and channel performance against that key event, which tells you which source produces enquiries rather than clicks.
For a transactional app, the useful set is the commerce funnel across viewing an item, adding to cart, beginning checkout and purchasing, plus a retention view. Retention is the number a lead generation site has no equivalent of, and for an app meant to be used repeatedly it matters more than the first purchase.
Funnels, and where things actually leak
A funnel exploration shows the steps users take to complete a task and how well they succeed or fail at each one [8]. It is the report that converts "our conversion rate is low" into "sixty per cent of people leave at the delivery details step", which is a problem someone can actually fix.
One configuration detail produces a lot of confused conversations. In a closed funnel, users must enter at the first step and move in sequence, so someone joining midway is not counted unless they later complete step one. In an open funnel, users can enter at any step and are counted from their first qualifying action, though they must still complete the remaining steps in order [8]. Each user is counted once per date range, on their first qualifying sequence [8]. Pick the wrong one and the numbers look broken while behaving exactly as configured.
How it gets implemented, and why it breaks
In our experience most broken analytics is broken at implementation rather than in the tool, and the mechanism is worth understanding because it explains why tracking dies without anyone noticing.
Tag management. Google Tag Manager lets you configure and deploy tags from a web interface without editing site code for every change [9], and Google states plainly that it is free [9]. For a UAE SME the benefit is that marketing changes stop requiring a developer release. The risk is that anyone with access can add tags nobody reviews, so name an owner for the container.
The data layer. This is the part that separates tracking that survives from tracking that does not. A data layer is a structured object your site populates so tags read from a predictable place. Google's stated reasoning is that its tags are designed to reference information added to the data layer in an organised and predictable way, rather than by parsing variables, transaction information and other signals scattered throughout the page [10].
Read that as a warning about the alternative. A tag configured to read a price off the visible page works until a developer changes the markup, at which point it silently starts recording nothing. Nobody gets an alert. The number just quietly goes wrong, and someone notices two quarters later.
Server-side tagging. This runs tag logic on infrastructure you control rather than only in the visitor's browser. Google states it can improve page performance by moving processing off the client, unlock more detailed user privacy controls, and improve data quality through server-side validation before data reaches downstream platforms [11]. For most UAE SMEs it is not the first fix. It earns its place at real traffic volumes, with several tags, and a genuine reason to control what leaves your site.
Apps use an SDK rather than a browser tag. Google Analytics for Firebase covers iOS, Android, Flutter and others, logging custom events, setting user properties and a user ID, and measuring screen views, transactions and ad revenue [12]. Firebase publishes a no-cost plan alongside a pay as you go one, with Analytics listed as a no-cost product [13].
A pattern we see constantly. A UAE business asks why enquiries dropped. The analytics shows a conversion event still firing at a healthy rate. The event turns out to be attached to the thank-you page, the thank-you page is reachable directly, and a bot has been finding it. The tracking was never wrong in the sense of being broken. It was measuring the wrong thing from day one, and nobody had written down what it was supposed to measure.
Why your numbers never match
Your ad platform and your analytics will never agree, because they are built to count differently, and Google documents the reasons rather than hiding them.
Analytics defaults to data-driven attribution while Google Ads uses ad-centric models [15]. Ads reports conversions by the date of the click, while Analytics reports by the date the action happened, so a click on the nineteenth followed by a purchase on the twentieth lands on different dates in each [15]. Google also advises allowing a day or two of processing before comparing final numbers, and warns that time zone differences between accounts produce discrepancies of their own [15].
Data-driven attribution itself distributes credit for a key event by comparing converting and non-converting paths, using signals including timing, device type, ad interactions and exposure order [14]. Conversions can be reattributed for up to seven days after the key event, and all models exclude direct traffic from credit unless the path consists entirely of direct visits [14].
On iOS, the vagueness is deliberate. App Tracking Transparency requires apps to request permission before accessing the advertising identifier or tracking a user across other companies' apps and sites, and apps cannot gate functionality on that permission [16]. Apple's ad attribution framework reports how many installs came from an ad without identifying individual users, withholding detail where volume thresholds are not met and delivering data through delayed, signed postbacks rather than real-time events [17].
The honest conclusion is that attribution gives you a plausible modelled story about which touchpoint contributed, not a ledger entry. Mismatches between platforms are the documented behaviour of the systems, not evidence that one is wrong. Choose one as your source of truth for decisions and stop reconciling to the unit.
One more thing worth knowing before you conclude tracking has failed: Google applies data thresholds that withhold report rows to prevent anyone inferring the identity or sensitive information of individual users, which particularly affects demographic and low-volume data [18]. A lower-traffic UAE site narrowing a date range can hit this and see blank cards.
Consent, and the banner that controls nothing
A consent banner does not control your analytics tags unless a developer has wired it to them. Our position on UAE law itself is set out in full in our cookie consent guide, and nothing here adds to it. The general principle is that Federal Decree-Law No. 45 of 2021 prohibits processing personal data without the owner's consent, with defined exceptions, and applies to processing through electronic systems inside or outside the country [21].
What this article adds is narrower and specific to tracking. Google's consent framework governs four signals covering analytics and advertising storage and use [19], and those signals only reflect a real choice if a developer has wired your consent banner into that API. Installing a banner and installing analytics are two separate pieces of engineering work. Until the second is done, your banner is not controlling your analytics tags at all. That is the same point our cookie guide makes about advertising tags, applied to a second category of tool.
On IP addresses, be careful with a claim that circulates loosely. Google states explicitly that Analytics does not log or store individual IP addresses from users in the EU, Switzerland and the UK, where the address derives coarse location and is then immediately discarded [20]. That statement is written for those regions. We could not confirm the identical wording for UAE traffic on a Google page, so we are not asserting it. If it matters to your compliance position, verify it directly rather than assuming it carries across.
Analytics is not exempt from the consent principle simply because it is not advertising. Event data can carry device and browser identifiers, and our published position treats those as personal data because they can be tied back to a person. That is our own reasoned inference rather than a quoted government definition, and we hold it consistently across both articles.
What it costs
A measurement setup starts from around AED 2,500 with us. That covers the measurement plan, designing the events and parameters, the data layer work, and registering custom dimensions so the data is genuinely reportable rather than merely collected. Ongoing analysis starts from around AED 1,500 a month, which buys attention rather than software: reviewing the numbers, watching funnels for movement, and saying what changed and what to do.
These are our own figures rather than a market survey, since no official body publishes rates for this work. Final pricing depends on scope, mainly on how many distinct actions matter and whether an app sits alongside the website. The tools themselves are largely free at SME scale, which is worth saying plainly: the reason your analytics is not working is not that you are on the free tier.
What to do in the first two weeks
- Write down the five business questions the data should answer, before touching any tool
- Map each question to an event, using the standard recommended name wherever one exists
- Check whether your existing parameters were ever registered as custom dimensions
- Mark the one or two events that represent a real enquiry or sale as key events
- Build one funnel, from arrival to that key event, and look at where people leave
- Confirm whether your consent banner is actually wired to your tags, or only appears to be
- Decide who owns the tag container, and review what is currently in it
Nothing on that list requires new software. It requires a decision about what you are trying to find out, which is the step that was skipped the first time.
If you have analytics installed and it has never told you anything you acted on, contact us and we will start by looking at what it is currently measuring rather than by recommending a different tool.
References
[1] Google Analytics Help, Events. support.google.com
[2] Google Analytics Help, Recommended events. support.google.com
[3] Google Analytics Help, Event collection limits. support.google.com
[4] Google Analytics Help, Custom dimensions and metrics. support.google.com
[5] Google Analytics Help, Data retention. support.google.com
[6] Google Analytics Help, About key events. support.google.com
[7] Google Analytics Help, Conversions versus key events. support.google.com
[8] Google Analytics Help, Funnel exploration. support.google.com
[9] Google for Developers, Tag Manager overview. developers.google.com
[10] Google for Developers, Data layer. developers.google.com
[11] Google for Developers, Server-side tagging. developers.google.com
[12] Firebase, Get started with Analytics. firebase.google.com
[13] Firebase, Pricing. firebase.google.com
[14] Google Analytics Help, Attribution models. support.google.com
[15] Google Ads Help, Understand your conversion tracking data. support.google.com
[16] Apple Developer, App Tracking Transparency. developer.apple.com
[17] Apple Developer, Ad Attribution. developer.apple.com
[18] Google Analytics Help, About data thresholds. support.google.com
[19] Google for Developers, Consent overview. developers.google.com
[20] Google Analytics Help, EU-focused data and privacy. support.google.com
[21] The Official Portal of the UAE Government, Data protection laws. u.ae
