The Warby Parker Mobile App Marketing Stack
A brief rundown of the technology we’re using to drive growth through the Warby Parker mobile app.
The Opinions Expressed In This Post Are My Own And Not Necessarily Those Of My Employer.
Segment
We evaluated Segment and mParticle for data management and ended up choosing Segment. There were three reasons we chose Segment:
- We could start immediately. Segment is geared towards developers who want to hit the ground running, immediately. If you throw down a credit card, you can start using the product right away. mParticle is more geared toward enterprise clients, and you need to sign a 1 year agreement to start using their product.
- The price was more favorable for our MAU count. Given our low Monthly Active User count, the price of Segment was lower. For apps that have enormous MAU counts, mParticle’s pricing becomes more competitive. But, we’re not there yet.
- Opportunity for web tracking. Segment started in the world of web, and they have a very mature web product. If we ever wanted to track web data alongside our app data, I’d feel more confident using Segment over mParticle.
This is just a brief overview from my standpoint, but you can hear from the founders of each company on this amazing Quora thread. Kudos to both companies for engaging in constructive conversation about how they differ.
Firebase
Our original plan was to use Firebase for Analytics, instead of Google Analytics. We quickly found out this was not going to work for us, as the more advanced GA e-commerce spec was not supported in Firebase. Although we’re not using Firebase for analytics, we are using them for 2 other features: App Indexing and Dynamic Links.
So far we’re happy with both products, save for a confusing interface that caused us to mistakenly delete a GA property that we thought was unused. Turns out that GA property was linked to our Firebase implementation. Luckily, we caught the error quickly enough so that deep linking and app indexing didn’t break, but it would have been nice if there was a clear link between the property and the Firebase app in the web UI.
Google Analytics
As referenced above, we’re using Google Analytics for app analytics. As far as setup, we’re using the Segment and Google Analytics server-to-server integration to push data into GA. So far we’ve been pleased with GA. It’s a reporting interface we’re accustomed to, and it’s been used by many other apps before us. Plus, it has robust support for enhanced e-commerce tracking. You’ll be able to track revenue by product, product category, SKU, etc. Added bonus: the Google Analytics iOS app is seriously addicting. You can quickly see app KPIs on-the-go from your iPhone.
We installed the Facebook SDK because we had originally planned to run install campaigns before we had an attribution platform. We didn’t want to be blocked from advertising by not having an attribution vendor set up. Ironically, we never launched a Facebook install campaign before setting up our attribution platform (AppsFlyer) so we didn’t get a ton of use out of the Facebook SDK. However, the Facebook SDK allows us to see other interesting demographic data (like how many Warby Parker app users are married, or the gender breakdown of users) and provides an opportunity for more detailed reporting on Facebook Install campaigns.
Appsflyer
We chose AppsFlyer for marketing attribution for a few reasons:
- Low startup cost. When we decided to sign on with an attribution provider, we had yet to spent a dime on driving downloads. I’ve heard from a few other e-commerce companies that it’s not economical for them to acquire customers via app downloads, so I wasn’t convinced that we would have a future in paying for downloads. Because of the uncertain future, I wanted to minimize the amount of cash we were on the hook for as part of the annual contract.
- Widespread market adoption. AppsFlyer is the most-used attribution provider.
- Integration effort. AppsFlyer was accustomed to integrating with Segment. This allowed us to cut down implementation time by piggybacking on the events we already had in Segment (purchase, add to cart, etc.).
In-house push notifications
We built push notifications in-house based on data that was already being used to trigger emails from our systems. The reason we built in-house instead of buying was because we wanted to see if purchase behavior would be affected by push before pouring cash into a vendor. Right now, we’re sending a few different push notifications (abandoned cart, abandoned Home Try-On, Home Try-On delivery notification) to 50% of eligible, opted-in app users to gauge the impact of push notifications on our user base.
If you have any questions about our decisions so far, or our plans for the future, feel free to hit me up. I’m always happy to chat about mobile vendors and technology.
Taplytics
We evaluated a few mobile A/B testing vendors and ended up choosing Taplytics because of their similar product and engineering culture, their competitive price, and the opportunity to start using them for push notifications. So far we’ve run 6 tests and have been pleased with the platform. The product team at Taplytics is open to feedback requests and moves quickly if the request makes sense within their roadmap. If you are accustomed to sophisticated, mature A/B testing products on the web (i.e. Optimizely) you’ll have to adjust your expectations while looking for a mobile A/B testing vendor. In my opinion, all of the native A/B testing products we looked at have some catching up to do, as the native testing market is less mature.
