At mParticle we’re excited to announce our latest innovation, providing an enhanced framework to handling in-app eCommerce data. mParticle empowers marketers to control their data and enable new services to help grow their businesses faster, without needing to write additional code or embark on additional development cycles. A few months back we began to overhaul our platform’s eCommerce data layer and, to the surprise of no one, it turned out to be a huge project. We designed an abstraction layer to help app marketers more easily access the evolving app services ecosystem, we exposed that layer and its respective paradigms via a shiny new set of APIs, and then we threaded it through our entire platform.
Though eCommerce has been around for nearly 15 years already, the way in which we all interact with offers and products online is still rapidly evolving. As with so many software services today, eCommerce has proliferated from traditional web to mobile, and now to a multitude of other platforms such as Apple’s soon-to-be-released tvOS. Businesses such as Airbnb and Gilt must (and have) become more sophisticated in their approach to eCommerce data as they increasingly rely on their apps to drive growth and monetization.
Today’s apps rely on an expanding ecosystem of 3rd-party services to make data-driven decisions, and our customers use mParticle to enable rapid integration, control cost, and privacy, and to achieve true interoperability between all of these services. It turns out, there are many different approaches to eCommerce among all of the 100+ services we support. Some services have no true notion of eCommerce, others have basic user-value tracking or transaction-level tracking, and then there’s the incredibly feature-rich Google Analytics Enhanced eCommerce.
True to our vision, we resolved to create an abstraction layer on top of this evolving ecosystem, and the next step was to invent a new set of data structures and APIs to represent those abstractions.
Separation of Concerns
One of my favorite parts of my job is how I can identify with mParticle customers – or at least the developers – and when designing APIs I get to put myself in their shoes. Across iOS, Android, and the mobile web (our current SDKs) there are different design patterns dictated by each platform, all APIs share some common goals. Distilled down, a “good” API strikes a balance between flexibility and ease-of-use. You want a system that is powerful enough to cover varying use-cases, but one that is also self-documenting and protects developers from themselves.
Our new eCommerce APIs were designed based on how our leading customer’s data gets activated across various analytics and marketing solutions while keeping it simple for those who only need basic eCommerce tracking, while also supporting the most advanced app developers.
Some of the key concepts we’ve introduced with this release are:
- A revamped product model that allows developers to represent the common properties of a product or service such as a name and a price, in addition to completely custom product attributes.
- A separate set of objects to represent what your customers are doing with those products, such as viewing them, adding them to a virtual cart, or purchasing.
- A set of helper APIs with strong typing and semantics, including a cart API that maintains state across application sessions, and a helper-API where each method performs a particular action on the cart.
We’ve decoupled the way that developers represent all of these concepts into separate objects and provided an API that we call CommerceEvent that allows you to tell us how it all stitches together in your app. For some light reading, check out the specifics of the new APIs on our doc site.
Activating this new data
Though these new data models and APIs were crucial to the project, the bulk of the work meant teaching our platform how to use all of this new data. We need to give our customers fine-grained control over where their data goes. We also enable our customers to span multiple services in parallel, without having to code specifically for each one. Finally, one of the most powerful features of our platform, our Segmentation Engine, needed an upgrade to allow for the brand new use-cases made possible by all of the new data flowing through the system.
These were some of the internal projects:
Improved Integrations – mParticle does the vast majority of its integrations with 3rd party services server-side. To grossly oversimplify it, data is sent from the app on your users’ phones to mParticle and then translated to the various integrations of your choosing by connecting with their API’s server to server. For this project, we needed to evaluate and in some cases refactor every one of these to account for the new data and to ensure that we were adapting the data in a reliable and predictable manner for each 3rd party service.
Data transformation and filtering – When developers create their app and instrument it with various forms of tracking, we want them to take a data-centric approach rather than a tools-centric approach. This means mapping data collection to business metrics and results and then to the various tools. In working with our customers, we evaluate the crucial funnels and data that should be collected in their app.
The mParticle platform can perform real-time transformation and renaming of your data per your specification in our web dashboard with a feature we call Custom Mappings. This allows apps to transform data to meet the pre-defined taxonomies of certain platforms without any additional coding. With the new “CommerceEvent” being such a rich object composed of varying attributes and sub-objects, this whole system needed an upgrade across our UI, backend, and mobile SDKs.
Segmentation – by collecting a superset of data, the mParticle Segmentation Engine has become critical to our client’s ability to target users outside of the app on platforms such as Facebook, Twitter, Google and others to improve retention and ultimately monetization. Some of the new dimensions you can add to your segments include:
- Cart Abandonment – users who add products to their cart, but who don’t complete a purchase.
- Actions on Products – users who performed a particular action on a product, such as viewing its detail-page, purchasing it, or requesting a refund.
- Promotions and Impressions – target users who viewed, tapped, or otherwise interacted with products and internal promotions.
- Product Bags – create custom, named list of products in your apps and find the users who have added or removed from them.