Value-Based Bidding in the Age of iOS 17: Challenges and Solutions
In the ever-evolving world of digital marketing, staying ahead of the curve is crucial for success. With Apple's iOS 17 privacy changes shaking up the industry, understanding the impact on value-based bidding and adopting solutions based on server-side tagging has become imperative to stay competitive.
In this article, I will explore the implications of iOS 17 on digital marketing, specifically value-based bidding strategies that are no longer durable, and how we at Jellyfish view the future of value-based bidding.
The iOS 17 privacy shift
Apple's iOS 17 has ushered in a significant privacy update called Link Tracking Protection. This update directly affects marketers and any company utilizing click identifiers, particularly in the context of user-level tracking protection within Safari Private Browsing, Mail, and Messages. Safari enjoys a substantial market share in the browser space (currently almost 26% market share, according to SimilarWeb), making this development a pivotal moment for marketers. It's not just a minor adjustment; it signals a potential new paradigm for measuring marketing efforts on the web.
Screenshot from Apple Press Release, August 2023
Tracking under scrutiny
Link tracking in iMessages, iMail, and private browsing on Safari on all devices will be affected. Given Safari's global popularity (second to Google’s Chrome), this is a substantial change that marketers must thoroughly comprehend. Understanding these shifts is vital for maintaining the effectiveness of marketing campaigns both now and in the future.
While Apple has not officially announced the parameters to be removed from URLs, they have hinted at the redaction of click IDs while sparing campaign IDs. This hint suggests that identifiers like Google click IDs (GCLID/DCLID) or Meta click IDs (FBCLID) may face redaction while UTM parameters remain unaffected. Click IDs are instrumental in tracking individual users from ad click, to website conversions, whereas UTM parameters operate at an aggregate level.
Additionally, user-level IDs play a vital role in the attribution capabilities of major platforms. Removing these IDs could lead to complications in reporting conversions, bidding strategies, and optimising conversion-based campaigns.
Of particular significance is Google Ads Auto Tagging, which forms a cornerstone of Google's advertising infrastructure. It heavily relies on the GCLID/DCLID as a key identifier for attributing clicks to web and app data. Furthermore, it is widely recognized as best practice, primarily due to the potential issues associated with custom tagging.
It is confirmed that the GCLID/DCLID parameter will be removed (private browsing mode), which is expected to disrupt the attribution process for Ads.
The impact on marketers
The adjustment may not be as disruptive as it appears for app advertisers, but operational requirements for app developers and product owners will likely increase. However, the uncertainty surrounding which URL parameters will be removed makes assessing the impact challenging for web advertisers. As stated above, attribution is the largest shift, potentially making reporting and optimising conversions in digital platforms harder.
The impact on analytics remains unclear and depends on the specifics of Apple's updates. We might witness a higher proportion of traffic being categorized as 'direct,' leading to decreased accuracy in distinguishing new versus returning users from iOS and Safari.
Out with the old, in with the new
Currently, the profitability process involves numerous ingestion models for the digital buying doors, such as Google Ads or Google Marketing Platform’s Search Ads 360 (SA360). Most of them are impacted by this new privacy change from Apple - leaving us with limited ‘durable’ and ‘future-proof’ solutions.
Let's explore solutions for profit ingestion:
- Offline Conversion Import - This is more complex to implement, modeling is incompatible, but profit is secure. It’s based on GCLID/DCLID, so it's not Safari/iOS compatible.
- Customer Match - This is the easiest to implement; batch uploads directly into Google, modeling stays intact. Limited to Google’s signed-in user base only.
- Secure File Transfer Protocol (sFTP) - This lets you bulk upload sheets directly to a Search Ads 360 endpoint. Based on GCLID/DCLID, it is not Safari/iOS compatible.
- GA4 measurement protocol v2 - You can send profit/offline user interaction data to Google Analytics using HTTP requests. It is not real-time and relies on GA4 processing.
- sGTM profit feed via Firestore, nicknamed Soteria - A knight in shining armor. Let me tell you more.
Introducing Soteria: Value Based Bidding with sGTM
First, what is sGTM?
In this evolving landscape, sGTM emerges as a resilient and durable measurement and activation solution. As it does not depend on non-durable IDs or click identifiers, making it a stable choice for maintaining bid strategies and leveraging AI/ML models based on enriched 1st party and modeled data.
For more information on sGTM and why Jellyfish believes it is the future of measurement, read this article.
Resilient/Durable Measurement & Activation
sGTM sets the foundations for the future of durable measurement, and keeps activation strategies intact - as it does not rely on non-durable IDs nor click IDs, keeping your bid strategies live and thriving.
Combining sGTM with Consent Mode and Enhanced conversions will supercharge your AI/ML models being based both on enriched 1st party and modeled data.
Utilizing sGTM with Firestore in Google Cloud Platform (GCP), Soteria connects sensitive profit data with SA360 transactions in real-time. This integration empowers marketers to send total and profit values at the product and basket level, enabling profit feeds to seamlessly integrate with bidding algorithms and AI models within a privacy-safe closed ecosystem.
How does Soteria work?
- CloudRun within GCP will be created to host sGTM infrastructure.
- A client-side Google Tag Manager (GTM) web container is configured with a purchase event to set up tagging on the site.
- The client’s website is set up to have an ecommerce purchase event in the data layer: this contains the revenue data. When a purchase is made, the event fires, sending the payload to sGTM.
- sGTM container will be built with a GA4 Client config tag to support sGTM requirements for conversion on transaction.
- A custom variable is attached to a tag, triggered by ‘purchase’ events, which pulls profit data from Firestore and replaces the revenue conversion value with the profit.
- Firestore will host all relevant profit data for item catalog. As Firestore sits within Google Cloud Platform (GCP), we’ll need to find the most efficient/effective pipeline to/from your profit source to automate your flow for a daily update to Firestore. (example: daily ingestion of Profit to a Cloud Storage bucket/BigQuery Storage → automate CSV file to Firestore)
- The updated event (with profit conversion value) is sent to Google Ads or SA360 via the Floodlight within sGTM via the Firestore connector.
What does a full sGTM deployment look like?
Why server-side tagging?
Data Accuracy: By reducing the reliance on browser-based tracking, sGTM minimizes data discrepancies and ensures that your insights are based on reliable information.
Privacy Compliance: sGTM aligns seamlessly with privacy regulations. It significantly reduces the exposure of user data to third-party scripts, fostering a more transparent and privacy-friendly user experience.
Improved Performance: With server-side processing, your website's load times remain optimal, enhancing user satisfaction and reducing bounce rates.
Future-Proofing: As the digital landscape evolves, sGTM provides a solid foundation for your measurement strategies, ensuring longevity and adaptability.
The iOS 17 privacy changes are reshaping the digital marketing landscape. Marketers must adapt to these changes by understanding their implications and exploring innovative solutions like server-side strategies such as Soteria to navigate this evolving terrain successfully.