How MakeMyTrip Approached Google Chrome’s Third-Party Cookie Deprecation
Introduction:
With online privacy changing rapidly, the upcoming end of third-party cookies has led to many changes in digital platforms. Recently, MakeMyTrip encountered a significant challenge with Google’s impending restrictions on 3P cookies. In this article, we’ll explore how we identified these issues within our platforms and detail the innovative solutions we implemented to maintain operational excellence.
Third-party cookie:
A third-party cookie is a small piece of data that gets stored in your web browser by a website other than the one you’re currently visiting. These cookies are commonly used by advertisers and analytics companies to track your online behaviour and interests across different websites.
As Google has started phasing out these cookies, If your website depends on third-party cookies, it’s time to act. In fact, Google has already rolled out this change for 1% of users and this will be rolled out for 100% by the end of Q4 2024.
Tools Used: Chrome dev Tool and Privacy Sandbox Analysis Tool(PSAT) Chrome extension
Identified Issues:
Issue 1: Third-party cookies were identified in our internal tool named MyDesk (test.com), which internal employees access through an intranet(private internal network). While our system utilizes a common authentication application (auth.com) for all Makemytrip applications, for MyDesk, we integrated this authentication application within an iframe. Since the domains of both applications are different so consequently, the authentication application is considered a third-party for MyDesk.
Flow
Resolution 1: Since our platform is safeguarded by a secure VPN, we were unable to utilize RWS (Related Website Sets). Instead, we implemented the concept of CHIPS, which Google recently introduced. Under CHIPS, we established a jar between the top-level site and the embedded site, enabling cookie sharing between them. Link
Cookies Having Independent Partitioned State (CHIPS): A partitioned third-party cookie is tied to the top-level site where it’s initially set and cannot be accessed from elsewhere. The aim is to allow cookies to be set by third-party services, but only read within the context of the top-level site where they were initially set. This allows cross-site tracking to be blocked.
// Header:
Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
// Javascript
document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"Issue 2: In many of our login flows, we rely on Google sign-in, utilizing the Google Sign-in API, which involves the use of third-party cookies.
Resolution 2: Google has already tackled this issue by releasing a new Google Identity API that works without 3P cookies. So, we have migrated our code to the new Google Identity API to ensure compliance and seamless functionality.
Issue 3: We utilize third-party services such as Adobe, Facebook, and New Relic for tracking and analytics, all of which utilize third-party cookies.
Resolution 3: After communicating with Adobe, they confirmed no impact post-restrictions. Furthermore, major service providers like Facebook and New Relic have already released new versions that work without 3P cookies.
Special Thanks:
We extend our sincere thanks to the Google Privacy Sandbox team for simplifying our integration process. The user-friendly APIs made integration seamless and significantly enhanced our productivity.
