Tray is an ecommerce Content Management System (CMS) provider with over 20 years of experience serving the Brazilian retail market. Merchants run online stores on Tray's infrastructure, which also provides services and integrations to manage business logistics, payments, promotions, and reporting.
Tray is a member of the LWSA group, and is a driving force in the ecommerce sector. Tray is trusted by over 180,000 clients who, combined, generated over US$3 billion in GMV in the first quarter of 2024.
Reliance on third-party cookies
Tray's technical architecture uses third-party cookies (3PCs) to provide third-party functionalities to merchant sites, particularly for the merchant's Backoffice administration panel used for store management. These cookies are essential for rendering content served from third-party applications that are hosted on domains other than the merchant's domain. Tray's research revealed that planned changes to how browsers handle 3PCs could potentially disrupt this capability. Because Tray serves as critical infrastructure for many online retailers, it's imperative that business can continue as usual—even while major changes are being made to how Chrome and other browsers handle 3PCs.
This case study walks through Tray's discovery of potential disruptions, their evaluation of potential solutions, and the successful solution put in place to make sure their sites are ready for changes to 3PCs.
Technical architecture
Microservices
Tray hosts all storefront and back-office applications on its domain, tray.com.br, and merchants can use a CNAME to serve these applications from their own custom domain. With this setup, shoppers will only ever see the store's domain, like merchant.example. Tray leverages a microservices architecture to deliver features and capabilities. This approach uses independent, self-contained applications that are each focused on a specific function. These microservices are then grouped into scopes based on their functional capabilities:
- Store: Encompasses applications responsible for storefront features like product display, search, and theme management.
- Purchase Flow: Manages the shopping cart, checkout process, and customer interactions during the purchase journey.
- Store Management: Provides back-office applications for tasks like administration, reporting, and data import.
- Integrations: Facilitates connections with external platforms to enable cross-marketplace listings, manage logistics, and more.
Backoffice application
Backoffice is a core application within Store Management, serving as the central administration panel for a seller's virtual store on Tray. Through this panel, sellers can:
- Register products
- Configure shipping and payment methods
- Create promotions
- Manage live broadcasts
- Oversee order flow
- Monitor sales reports
Because Backoffice brings together many microservices–some operated by Tray and some operated by third-parties–in a single interface, it is particularly susceptible to disruptions resulting from changes in how third-party cookies are handled.
CNAMEs for merchant customization
Tray utilizes CNAME records to seamlessly integrate storefronts.
When setting up a new store, merchants can
set up CNAMEs
to direct requests to applications hosted on Tray's domain,
tray.com.br. This means that when a customer visits a
merchant's website (such as example.com), a CNAME record redirects them to
Tray's domain while maintaining the merchant's URL in the address bar. This
creates a smooth user experience where content appears to be served directly
from the merchant's website.
Understanding CNAMEs
CNAME records function similarly to call forwarding on a phone. Imagine calling a friend at 555-0199, but they don't answer. The call might be forwarded to voicemail at a different number, like 555-0100. However, you, the caller, remain completely unaware of this redirection. The phone seamlessly connects you, and the voicemail greeting still displays your friend's original number (555-0199).
CNAMEs work in the same way for websites. When a user visits a merchant's
website (such as example.com), a CNAME record might redirect their request
behind the scenes to a different server, like assets.example.com. But from the
user's and browser's perspectives, everything happens on example.com. The
address bar displays the merchant's URL, and the user interacts with the website
as if the content originated directly from that domain.
Assessing potential disruptions
Tray's analysis of planned changes to 3PC handling revealed disruptions in the Backoffice application. When 3PCs were blocked, issues arose when loading pages from different domains within iframes embedded in backend pages. This applied to internal domains, which belonged to the company's own services, as well as to external partners who develop applications that integrate with Tray using its API.
For example, imagine a page on backoffice.merchant.example that embeds
content hosted by tray.com.br and other third parties.
Browsers would treat this embedded content as third-party due to the domain
difference, potentially restricting it under any 3PC limitations.
This setup could lead to several problems:
- Broken sessions: Blocked 3PCs can cause affected sessions to be broken, fragmenting user experiences by requiring users to sign in multiple times, or otherwise disrupting or causing inconsistencies within Backoffice pages due to malfunctioning iframes.
- Integration challenges: Partner applications and internal services that integrate with Tray's backend using its API could face similar difficulties due to 3PC restrictions.
The following figure illustrates this scenario:
- A user accesses the Backoffice application hosted on
merchant.example. - Embedded applications reside on different domains – some on
[tray.com.br](http://tray.com.br), which is owned by Tray, and others on third-party vendor domains (third-party.example). - This domain difference triggers 3PC restrictions, potentially causing issues with the embedded applications.
Analyzing third-party cookie dependencies and solutions
Testing critical user journeys
Tray's testing and analysis were aimed at improving website performance and user experience, with a focus on third-party integrations and preparation for a future where many users browse without 3PCs.
Tray used the Privacy Sandbox Analysis Tool (PSAT) and Chrome DevTools to analyze key user flows for customers and merchants. This involved testing page loading within iframes, checking if user sessions remained valid, and making sure third-party applications continued to function as expected. Testing encompassed various user roles, devices, and browsers (including Chrome, Firefox, and Safari) to identify potential cross-browser compatibility issues. Tray used PSAT and Chrome Dev Tools to categorize cookies and assess their impact on the user experience.
This analysis was a vital step towards ensuring a smooth and consistent user experience, adapting to a future where third-party cookies may be limited or unavailable.
Analyzing Privacy Sandbox solutions
Storage Access API
While the Storage Access API (SAA) could potentially address Tray's disruptions and is supported by all major browsers, it wasn't the best fit for the business for two main reasons:
- The embedded content only needed to access cookies on the origin where it was embedded, not to access the same cookies across multiple sites.
- The browser prompts associated with SAA were not ideal, especially since cookies weren't being used to track users across sites.
CHIPS
CHIPS offered a strong solution with an excellent user
experience for cross-site embeds. The Partitioned attribute was
straightforward to implement and had no discernible impact on user interaction
for users in Chrome. CHIPS was not supported by other key browsers when Tray was
making changes to their service, so they elected to move their
owned-and-operated embeds into the same-site as the top-level application to
provide a consistent experience across browsers. Third-party embedded content
relies on CHIPS in Chrome and opens a new window (first-party context) in other
browsers. Since Tray's initial implementation, however, Firefox has confirmed
plans to ship CHIPS soon, and Safari has begun to
add support
for the Partitioned attribute, starting with their Technology Preview.
We thought that CHIPS was an elegant solution and are glad to see it being adopted across multiple browsers. We decided to keep the CHIPS solution in addition to moving things to first-party sites so that we can support all browsers even before they adopt CHIPS.
— Takashi Tanaka, CTO of Tray
Browser compatibility, W3C, and standards
Chrome plays a pivotal role within the standards community. Active participation in W3C Working Groups and Community Groups, such as the PrivacyCG, is crucial for influencing the broader browser ecosystem to adopt new web technologies.
The Privacy Sandbox works with the web ecosystem to continually evolve APIs like CHIPS based on industry feedback and engagement. This transparent and standards-driven approach has been instrumental in driving the adoption of CHIPS across other major browsers.
Durably solving for third-party cookie dependencies
Tray supports merchants and their customers across all types of devices and browsers. A solely CHIPS-based approach would have been preferred, but additional changes were made as well to support other browsers that did not support CHIPS at the time.
Tray's approach to addressing the disruptions caused when 3PCs are not available involved two main strategies.
1. Internal applications
Fully-operated Tray microservices—including Live Shop, Dropshipping, and Invoice Issuer—were updated so that the source of embedded content would inherit the CNAME set up by the merchant. Simply put, the embedded content was updated to be first-party with the page embedding it—ensuring that there were no disruptions due to third-party cookie changes.
2. Third-party applications
For third-party applications accessed through Backoffice, Tray implemented a more dynamic approach. Here's how it works:
- Partitioned attribute implementation: The implementation of the
Partitionedcookie attribute was maintained for trusted vendors, making it possible for the third-party applications to effectively set cookies on browsers that support CHIPS. - When third-party cookies are blocked: If the user's browser blocks 3PCs, the third-party application opens in a new (first-party) window. This avoids opening problems and ensures continued operation, even with 3PC restrictions.
- When third-party cookies are allowed: If the user's browser allows 3PCs, the application continues to open within iframes as before.
Visualizing the solution
The following figure illustrates the solution. By inheriting the store's main
domain (merchant.example), all embedded applications appear to originate from
the same source. This makes all of the widgets first-party to each other,
meaning that 3PC restrictions are not a factor. Because all of these frames
become first-party to each other, the privacy principles take on those of other
first-party cookies: they are only accessible in the first-party context and
limit the potential for cross-site tracking.
Any third-party services not owned by Tray use the Partitioned attribute to
set CHIPS cookies, meaning that they are also only accessible in the context in
which they were set and limit cross-site tracking potential.
The bottom line
- There isn't a one-size-fits-all solution to privacy on the web; there are many ways to achieve frictionless user experiences while still preserving privacy.
- Consolidating resources into the same top-level domain allows cookies to function even with third-party cookie restrictions.
- CHIPS may be an easier solution than migrating all resources to the same top-level site.
- Tray's solution is durable and works across browsers. As additional browsers implement support for CHIPS, it can be considered to be a reliable cross-browser solution for scenarios like Tray's.