#ga4 #googleanalytics
What is Measurement Protocol, and When Should You Use It in GA4?
Table of Contents
- What is the Purpose of Measurement Protocol?
- Advantages of Measurement Protocol
- Disadvantages of Measurement Protocol
- Best Practices
- Summary
What is the Purpose of Measurement Protocol?
Measurement Protocol (MP) is a method of sending data to Google Analytics 4. It allows the collection of data from any Internet-connected source, whether it’s a website, mobile application, CRM, or a coffee vending machine.
Most data in GA4 comes from the frontend, which includes codes placed on the page and visible to every user, similar to HTML on a webpage. When a user makes a purchase on a site, an event called “purchase” is generated, which then sends the data of the purchased products to GA4 (via Google Tag Manager or directly). We later view this data in GA4 reports.
However, sometimes this method doesn’t allow the sending of data for all purchases (or other conversions) to GA4. Examples include:
- Lead pages where users leave their contact information by filling out forms, but the purchase occurs later, e.g., after email or phone contact.
- Pages where payment can only be made for some products online, while others require signing a contract or other contact, making the purchase not finalized online.
- Pages where users buy subscriptions that are regularly renewed. Customers pay for the first month during the Google Analytics session, and subsequent payments are automatically deducted from their card. By default, GA4 can only record the purchase for the first month.
- Another case is pages where a purchase can be made, but users do not return to the thank-you page, or there are errors or canceled purchases, resulting in significant discrepancies between CRM and GA4 data.
In each of these cases, in addition to default online (frontend) data transmission, additional data (backend), including offline data, can be sent. We can retrieve customer data paying a monthly subscription from CRM and send it to GA4. This requires the use of Measurement Protocol, which is a method of processing data from the source tool (e.g., CRM) to the target tool (GA4). It is an API, a way for two tools to “communicate” because they do not have default integration (such as Google Ads and GA4). This requires the involvement of a programmer who will implement Measurement Protocol and test the transmitted data in GA4.
Sending Data to GA without MP
Diagram of sending data to Analytics without MP (only frontend data):
Sending Data to GA with MP
Simplified diagram of sending data to Analytics through MP (frontend + backend data):
Advantages of Measurement Protocol
Precise Data
Measurement Protocol enables very precise data transmission to GA4. Let’s look at an example: Users confirm a purchase on the website and can:
- Make an immediate payment,
- Not make a payment,
- Make a payment after some time.
Additionally, the order can have different fulfillment statuses, such as:
- In progress,
- Sent to the customer,
- On hold,
- Canceled by the customer.
Frontend tracking (based on codes invoked in the source of the website) allows noting purchases after the user’s chosen online action, e.g., clicking the “Pay” button before the actual payment. As a result, data on unpaid purchases are sent to Analytics. By using MP and utilizing CRM data, you can precisely choose which orders to send to GA4, for example, only paid transactions, making tracking more precise.
Offline Data
Measurement Protocol allows for the transmission of offline data, which is not tracked by default in Google Analytics.
Tracking the Full User Journey
Analytics enables tracking clicks on email addresses and phone numbers, as well as copying such data by the user. It allows tracking form submissions. However, it doesn’t provide the capability to convey what happens afterward. Whether the user received a response via email or phone and if a contract was signed, Analytics lacks access to such data because these user actions occur outside the website. Sending such data requires connecting frontend data (user actions on the site) with backend data (CRM, database) and sending them to Analytics using Measurement Protocol.
Conversions After Email and Phone Contacts
Data about actions performed outside the site can be supplemented using MP. In this case, there might be a lack of information about the traffic source assigned to the conversion. This is due to the absence of information about the session to which the conversion can be attributed. Fortunately, there is a possibility to manually add this information.
Data on Renewable Payments, Subscriptions, and Packages
Conversions of this type often occur outside the website, so they are not tracked by Analytics. An exception is websites that require actions on the site to purchase a package, such as filling out a form for logged-in users and confirming the purchase. If subscription and package data are outside the site, they can be transmitted via MP.
Product Return Data
Product returns often occur via email, making it difficult to complete this data in Analytics. Measurement Protocol can come to the rescue here.
More Precise LTV Tracking
Lifetime Value (LTV) is the amount a customer spends on products or services throughout their entire period of using a company’s services. This indicator helps distinguish returning and regularly buying customers from those who make occasional purchases.
In the context of optimizing advertising campaigns, this is important information. For acquiring customers with high LTV, it’s worth spending more advertising budget or setting higher target cost per conversion (tCPA) because it will pay off in the longer term. If the site offers renewable packages or subscriptions, LTV will increase each month. Measuring it is challenging when package renewals occur outside the site. Measurement Protocol can help complete data to more accurately measure LTV and facilitate data analysis and marketing campaign optimization.
Disadvantages of Measurement Protocol
Every rose has its thorns, and MP is no exception. The solution is not easy to implement and comes with several challenges.
- Connecting frontend and backend data requires collaboration with a programmer who specializes in both areas.
- Implementation on the programmer’s side is more time-consuming than classical frontend code implementation. This may mean higher implementation costs.
- At the time of the publication of this article in the winter of 2023, GA4 is still a developing Google product that gains additional features and improvements. Full GA4 documentation is not yet available, and many things may change, including Measurement Protocol, as GA4 gradually becomes more user-friendly.
- Events sent by MP are by default associated with values (not set) in some reports.
- Sending events by MP with a 72-hour delay compared to the user session time means that GA4 will not be able to connect events with the session, which can result in values (not set) in reports, e.g., in Session – source/medium.
Connecting Frontend Data with Measurement Protocol
Connecting frontend data with Measurement Protocol requires retrieving the user identifier from the cookie file (client_id) and the session ID (session_id), and connecting them through MP.
In the absence of these values, GA4 is unable to connect frontend data. This means that an event, such as a purchase, will not be linked to the session initiated by the user. As a result, (not set) values appear in reports related to sessions, such as Session – source/medium.
The same problem arises when event data is transmitted after 72 hours from the session duration – GA4 will then create a new session to which it will assign the action. Therefore, it will not be possible to attribute the event to the original source of traffic.
If we transmit data after 72 hours, we can manually supplement information about the source/medium of the session by retrieving it from the source tool, such as CRM. In practice, however, we may lack such data – CRM typically does not collect them.
Precise Tracking Plan
Proper operation of MP requires a precise determination of which events are to be sent. Should it be every paid transaction, or only fulfilled orders? Should canceled orders be recorded as purchases and returns, or excluded from tracking? The more complex the transaction process, the more topics to consider. The moment of order placement and the moment of payment can differ significantly, and exceeding 72 hours from the user session complicates implementation.
Technology, Location, and Page Data
Events transmitted by MP do not provide information about technology, location, and event pages. This means that with frontend events, we will see browser data, screen resolution, country, city, language, or page paths, while with MP events, (not set) values will appear. In the case of the device category, MP events are often entirely assigned to desktop.
Lack of Additional Configurations
A thorough implementation of GA4 forms a strong foundation for further configurations. GA4 frontend codes are commonly used not only for GA4 but also for implementing other tools, such as Facebook events, Bing, Google Ads, or Google Ads remarketing. In the case of events transmitted by MP, there is no possibility to use this code for implementing, for example, conversions with the Google Ads tag or the Facebook tag – this requires frontend codes and Google Tag Manager. However, sending GA4 events to Google Ads is possible without any issues, using the integration of these tools.
Based on events from MP, additional configurations in GA4 cannot be set up, which is a useful feature of this tool.
Best Practices
- Implementing MP is worth planning more time on the programmer’s side than implementing frontend codes. Before starting the project, it’s advisable to consult the topic with the programmer, showing what type of codes are to be implemented.
- Efficient implementation requires collaboration between the programmer and a Google Analytics specialist, as testing the functionality is not possible to carry out alone.
- When implementing MP for e-commerce, it’s important to precisely determine which transactions are to be transmitted to GA4.
- When implementing purchase tracking through Measurement Protocol, it’s also worthwhile to implement standard e-commerce code to have a basis for configuring conversions in tools other than GA4, such as Google Ads, Facebook, Bing.
Summary
Measurement Protocol is a powerful tool that can be used to collect very precise data from various tools, such as selected types of transactions from CRM. The function also allows supplementing GA reports with data that cannot be collected by default, such as offline conversions after phone contacts with customers or subscription purchases. It is a response to the concern of many marketers and entrepreneurs who would like Google Analytics to show more accurate data.
On the other hand, Measurement Protocol is more difficult and time-consuming to implement. Using it may be associated with gaps in GA4 data, especially when sending data with a delay.