Company News, Performance Marketing

Examination of e-commerce data practices

Basil Shikin
Mar 31, 2025

Introduction

In today’s digital landscape, modern advertising and analytics models rely on a diverse set of data points to deliver personalized experiences and drive business outcomes. Among the most commonly utilized data types are IP addresses, which are inherently transmitted with every web request; device information, though often limited in scope on the web; and cookie data, which has become increasingly constrained by privacy mechanisms like Intelligent Tracking Prevention (ITP). Cookie data typically consists of randomly generated identifiers created by various advertising platforms — such as those from Meta, Google, and AppLovin—as well as analytics providers. These identifiers are designed to function within the boundaries of a single app or website, aligning with the goals of contemporary privacy frameworks that aim to curb cross-site tracking.

These identifiers are available across web frameworks, which can create opportunities for data sharing. In other words, all identifiers may be accessible to every pixel installed, enabling them to be appended as “custom attributes” to objects like shopping carts. These attributes are then transmitted as part of standard requests to multiple parties.

This post explores the data flow of prominent identifiers — those from Google and Facebook — and examines how they are handled across e-commerce ecosystems.

Methodology

To investigate these data flows, we used Grok to generate a custom Firefox plugin (available on GitHub) that traces how identifiers are shared across partners. This tool provides a visual representation of data transmission, highlighting which entities receive specific identifiers:

While similar insights can be gleaned using browser developer tools like the “Network” tab or third-party software such as Charles Proxy, this plugin simplifies the process and serves as a starting point for manual investigation. Using Firefox equipped with this plugin, we visited multiple e-commerce websites to observe real-world data-sharing patterns.

We found that most identifiers are passed on the pre-checkout page, although it is worth examining other pages as well.

Examples

Let’s first examine a few examples to establish how the tool operates.

crocs.com

We can see that Facebook ID is not sent to b.applovin.com in the network tab (the whole attributes section is not present):

thewoobles.com

On thewoobles.com, it’s clear that identifiers are transferred to multiple domains (including AppLovin):

Further investigation shows that the identifiers are included as cart attributes by a third-party library, Elevar. Elevar is an unrelated third-party service that offers analytics and tracking solutions for brands to optimize data collection.

A more comprehensive check shows that blocking Elevar’s initialization sequence stops these identifiers from being appended to the cart attributes:

These examples demonstrate the operation of the tool and underscore how widely identifiers can propagate across e-commerce platforms, often facilitated by standard integrations.

False positives

Data flow analysis is not without its challenges, and misinterpretations can easily occur without careful scrutiny. I wanted to highlight a few false positives that emerged during our investigation.

trueclassictees.com

One can see identifiers sent to various partners:

There is a particular cart attribute, igId, that is sent to AppLovin (and potentially other standard marketing pixel integrations):

Although it may seem that it has something to do with Instagram, further research shows that this is an identifier created and maintained by Intelligems, a profit optimization tool:

This false positive highlights the importance of context in data analysis.

Website keys

Certain post-back values that appear random, such as AppLovin’s connectEventKey, may seem like unique identifiers:

These keys serve as a static pixel configuration rather than a tracking mechanism, despite looking seemingly random. This configuration string does not identify an individual user.

Conclusion

Privacy frameworks enforced by apps, browsers, and platforms have leveled the playing field, ensuring that all companies operate within similar constraints. However, understanding how data flows through these systems requires a nuanced grasp of technical integrations and their intended use cases. At AppLovin, we leverage standard APIs and mechanisms for data collection and processing while maintaining a disciplined approach by discarding any extraneous information we’re not authorized to handle.

Our technical stack is designed with a long-term vision: to build a robust, innovative product that drives growth across industries. AppLovin aims to empower businesses while respecting the evolving landscape of user privacy by harnessing cutting-edge machine-learning techniques and prioritizing sustainable practices. This balance of innovation and responsibility remains at the core of our mission.

*Grok 3 was used to support the drafting process of this blog. Final content and conclusions are the author’s own.

Top Picks

Browse by business objective