That is almost exactly what UTM url parameters are [0]. We use these and via them our other tracking collaborates our theory on Facebooks tracking.
There is actually a real problem with tracking via cookies on Facebook ads when the destination is a website. The ad click will open in a Facebook "In App Browser", any cookie that you (or any analytical service) sets will be within that IAB. If the user then uses the "open in Safari/Chrome" option that tracking can be broken as there is no cookie. Ideally you want your visitor to either complete their transaction within the IAB or to use the "open in Safari" option immediately so that any tracking parameters are copied to the other browser allowing the cookie to be set.
In our case the majority of our customers will have a better experience outside of the IAB and so we have a popup that prompts them to use "open in Safari" before navigating away from the first page view. We actually implemented this after noticing a very high drop out rate for iOS Facebook IAB users during our checkout. What was happening is address/payment card autocomplete isn't available within the Facebook IAB and people were clicking "open in Safari" during the checkout in order to use it, they would then find themselves with an empty shopping cart, hence the drop out.
So not only is the Facebook/Instagram "try to lock users into our own browser to track them" thing user-hostile, but it actually harms companies that are using ads by having them drop in the middle of the funnel?
That's really interesting, I'm going to check our analytics to see if the same thing is happening.
Another way you could potentially get around it is to fingerprint the user and store the basket contents server side and present them to that fingerprint.
This is interesting. Are you saying because some user switch to safari during checkout and tracking lost here? Since cookie will be cleared. But how about these special query param as you mentioned? That still can be maintained for tracking?
UTM parameters can be identifying but not generally considered private - rather the opposite - so while you can link your cookie to UTM parameters and join with other UTM-keyed traffic data for useful results, you can't do the inverse and use knowledge of UTM parameters as sufficient proof to recover a session cookie.
There is actually a real problem with tracking via cookies on Facebook ads when the destination is a website. The ad click will open in a Facebook "In App Browser", any cookie that you (or any analytical service) sets will be within that IAB. If the user then uses the "open in Safari/Chrome" option that tracking can be broken as there is no cookie. Ideally you want your visitor to either complete their transaction within the IAB or to use the "open in Safari" option immediately so that any tracking parameters are copied to the other browser allowing the cookie to be set.
In our case the majority of our customers will have a better experience outside of the IAB and so we have a popup that prompts them to use "open in Safari" before navigating away from the first page view. We actually implemented this after noticing a very high drop out rate for iOS Facebook IAB users during our checkout. What was happening is address/payment card autocomplete isn't available within the Facebook IAB and people were clicking "open in Safari" during the checkout in order to use it, they would then find themselves with an empty shopping cart, hence the drop out.
0: https://en.wikipedia.org/wiki/UTM_parameters