As the documentation states Measurement protocol is used for this purpose:
- Measure user activity in new environments.
- Tie online to offline behavior.
- Send data from both the client and server.
You can even find some of the basic hit payload examples in the dev docs here https://developers.google.com/analytics/devguides/collection/protocol/v1/devguide#commonhits. These hits will be valid yet if sent as is it is a question how valuable the data will be perceived once in reports. A suggestion would be to widen. Always. Making the hit valid and valuable at the same time.
The issues with MP can best be explained by using a simple example such as:
Company A sells product B in multiple countries. The process contains multiple steps. 1st step where a user visits the site and fills in and successfully submits a lead form. After validation and internal risk check we enter 2nd step where the initial transaction is processed. Delay between step 1 and 2 can be up to 14 days. 3rd step – a user can have a recurring payment contract which automates billing process each 30 days – there is no need for the end user to visit the site in order to confirm.
Scenario – Sending a valid hit with bare essentials in step 2 and 3 results in:
Device, Geo and traffic attribution will be or can easily be skewed. For instance sending a minimum valid hit will basically send information which will be generically attributed to the IP of the server sending the hit (messes up geo attribution), device sending the hit (messes up device attribution), and traffic defaults to direct (which is in some cases fine as GA uses last non direct traffic source attribution meaning IF any campaign exists prior to the MP hit tied to a specific Client Id within the Campaign Timeout window (6 months by default) the direct traffic will just be overridden).
One additional thing which may happen if scenario follows this path:
- step 1 form submit via google / cpc
- between step 1 and step 2 an additional session / visit happens via google / organic
- step 2 sends the transaction to GA yet the transaction will be attributed to google / organic – so it is a question which of the sources you want the transaction to be tied with – cpc or organic?
- subsequently recurring transaction attribution for step 3 will always subscribe to the latest known campaign and not the initial source of Lead or Transaction
In order to prevent this from happening there are some additional parameters which you should:
- store (in your internal system for processes such as lead form submits) and
- send with the measurement protocol hit
Parameters for widening the MP hit (solving attribution)
dl – document location
Circumvent any hostname filtering (dp and dh parameters as options to this)
uip – user IP
ua – User agent
Preserve info on user agent (optional)
ds – Data source
Segment on data source. (cdN (custom dimension) as option)
cn/cm/cs/gclid/dclid/dr – traffic – campaigns from UTM / Adwords or DC / document referrer / (none if no info exists or create a virtual direct?)
Preserve traffic – partially. The issue is to preserve attribution for the traffic source which generated the sales – if no info would be provided some mid newsletter driven session may miss attribute results.
Sending the Measurement protocol hit
Prior to pushing all your work to production you should definitely test the setup and outcomes using https://ga-dev-tools.appspot.com/hit-builder/ and a dummy Google Analytics property. In most cases you will send the hits as events, non interaction ones so make sure ni parameter is set to 1. This may challenge the way you see the standard reports as if you send a non interaction hit something unexpected will happen – no session will be created but there will be a user reported for the period in question – the attribution will stay intact though. MCF reports will attribute and report as expected.
I would really be interested to know which other parameter you find essential or some of your MP cases where the valid hit is just not enough – Happy tracking!