# Migrating to Optimizely at Groupon

DevFeed: [Migrating to Optimizely at Groupon](<https://devfeed.tech/articles/migrating-to-optimizely-at-groupon-26223.md>)

Original publisher: [Read original article](<https://medium.com/groupon-eng/migrating-to-optimizely-at-groupon-27fa56f86d12?source=rss----5c13a88f9872---4>)

Author: Andres Otarola

Published: 2022-09-12T21:17:34Z

Content type: article

Language: en

Sources: [Groupon Engineering -- Medium](<https://devfeed.tech/sources/groupon-engineering-medium.md>)

Topics: [experiments](<https://devfeed.tech/topics/experiments.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [API](<https://devfeed.tech/topics/api.md>), [Caching](<https://devfeed.tech/topics/caching.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [article](<https://devfeed.tech/tags/article.md>), [cache](<https://devfeed.tech/tags/cache.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [components](<https://devfeed.tech/tags/components.md>), [data](<https://devfeed.tech/tags/data.md>), [experimentation](<https://devfeed.tech/tags/experimentation.md>), [experiments](<https://devfeed.tech/tags/experiments.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [pipeline](<https://devfeed.tech/tags/pipeline.md>)

## AI overview

Groupon describes migrating its in-house experimentation pipeline to Optimizely's cloud-based solution. The article outlines the existing data transport and experiment engine components, the migration challenges of maintaining backward compatibility and supporting web and mobile clients, and the mobile experiment flow using a public-facing API and cached in-memory data.

## Source excerpt

Sharing experiences and learnings 🧪Photo by Alex Kondratiev on Unsplash Experimentation is a key indicator of whether a feature will be appealing to users, maybe fall flat, or worse: cause a negative impact on them. Here at Groupon, we have been data driven for years, so it is in our nature to A/B Test everything that we present to our customer base. The objective of this article is to give you some insights into how we migrated our existing experimentation pipeline onto Optimizely's solution by swapping certain components from our pipeline. Let's dive in. As mentioned, we already had an existing experimentation pipeline, which can be generally split into two main components: Data transport Experiment engine Generalised diagram of experiment eventsData transport This is the layer that is responsible for transporting the events of an experiment. "What is an impression event?" you may inquire. It's an interaction of a unique user with the treatment of an experiment. For Example, an experiment that presents either a red button or a green button to a user will be counted as an impression event with the chosen variation (either a red button or a green button). Such events are handed over to specialized channels which end up being cleaned up by a central process in charge of canonicalizing the events so upstream services can easily parse the data. It is important to emphasize that the Data transport layer is ignorant of the details of the experiment engine. Experiment engine This is the actual component that decides how an experiment is performing based on the events it is receiving, as well as providing the information of the currently available experiment to query from. (In our case this implementation varies per client; more on this later on.) Enter Optimizely When we decided to switch from our in-house experimentation solution to a cloud-based one, in this case, Optimizely, we immediately faced various challenges: Keep backward compatibility (Even more so for Mobile!)