Editor’s Note: Throughout this series, when I refer to “marketing analytics,” it includes digital marketing analytics or web analytics as it used to be called.
In the previous post of this series, I described how the roles of marketing and product teams have been impacted by digital transformation and shared an example of how blurred the lines between marketing and product can become when it comes to digital experiences. This post will explain how marketing and product analytics products differ and where we may be headed in the future.
As I stated in the previous post, there are many cases in which marketing and product questions can be answered by marketing or product analytics products. This is because there is a lot of overlap in their functionality. Both types of products allow you to:
- Count unique visitors
- Track content
- View customer paths
- Create conversion funnels
- Track digital marketing campaigns
- Build segments/cohorts of users
- Create dashboards
- etc.
Having worked with both types of digital analytics platforms, I have found that what most differentiates marketing analytics and product analytics vendors is mainly how they emphasize different aspects of features that they have in common. The following will outline the differences as I see them.
Website vs. Apps
For many years, the main reason an organization would choose to use a marketing analytics vendor versus a product analytics vendor was whether it wanted to perform analytics on a website or a mobile app. For reasons I outlined in this post when mobile apps arrived on the scene, they became the domain of product teams while websites had traditionally been the domain of marketing teams. This bifurcation of departments often led to each team choosing its own digital analytics product, marketers choosing marketing analytics products, and product teams choosing products like Amplitude (or its product analytics competitors). At the time, mobile apps were much smaller in terms of digital traffic, and in some cases, different personas used the website than the mobile app.
But now that mobile apps have grown in popularity and the same users are accessing both apps and websites, this bifurcation has led to inconsistent customer experiences and made it more difficult for analytics teams to view the entire customer experience. This is one of the reasons that I have predicted that there will be a convergence in digital analytics products over the next few years.
Session/Page View-Based vs. Event-Based
For most of my marketing analytics career, marketing analytics products were based upon sessions and page views. Borne out of the website era, marketing analytics vendors captured unique visitors, visits, and page views by default. While there were always events within those page views and sessions, the architecture was built around pages loading and sessions (typically lasting until 30 minutes of consecutive inactivity). This model first encountered challenges when organizations began deploying single-page applications (SPA). Marketing analytics vendors had to create workarounds to account for the activity within page views.
Conversely, product analytics tools have traditionally had an event-based model that worked in the app or website paradigm. The event-based model made sense to product teams that like to track many customer actions, many of which take place between page views. Product teams tended to desire a deeper level of granularity than their marketing counterparts. Looking back to the product landing page example in the previous post, you can see how some of the intra-page interactions, such as filters, product image hovers, etc., might be better suited for event-based tracking vs. page-based tracking. In its new research report, Gartner describes it this way: “…the session-based structure is becoming stale and not compatible with modern use cases.”
Cookies vs. Users
For most of my career in marketing analytics, relatively few customers were lucky enough to know who was using their website. The rare example of this was banks that had customers authenticate via a login. For this reason, marketing analytics vendors didn’t have a notion of a “user” in their product. It was challenging if you wanted to see everything that “Joe Smith” did. You could identify his cookie ID, build a segment for that ID, and look at endless path flow reports. Still, there was no easy way to see an individual’s full event stream and the properties/dimensions associated with those events.
By contrast, many mobile apps and other complex digital experiences require authentication. For this reason, product analytics tools [like Amplitude] have a defined user profile that collates information on the customer and a listing of all their activity. In some cases, product analytics tools even allow you to augment the user profile with additional user attributes like a CDP.
The user profile feature within product analytics tools also required more advanced identity resolution capabilities to stitch together authenticated users across sessions and devices. After all, you cannot have an accurate user profile and event stream unless you can accurately identify the same customer across sessions and devices – and in a way that doesn’t rely on cookies. This is an area where marketing analytics vendors originally relied on 3rd party cookies (or their advertising network) for identity resolution, but in recent years have shifted to first-party and other means of user identity resolution.
Acquisition vs. Retention
One of the original use cases for marketing analytics products was new customer acquisition. When Google acquired Urchin and turned it into Google Analytics, it was a way that digital marketers could see the performance and returns on their investments in paid search and display advertising. In many ways, digital advertising was the impetus for the entire digital analytics industry! For this reason, you can still see today how vital tracking digital channels and campaigns is to marketing analytics vendors, and they have great features in this area. For many years, product analytics vendors didn’t focus on features related to customer acquisition. There were ways to capture campaign tracking codes, but attribution features were limited (at Amplitude, we are now investing heavily in acquisition functionality).
Product teams have traditionally been more interested in what customers and prospects did within the digital experience than how they got there. Therefore, product analytics vendors tend to have deeper functionality for tracking customer retention. In Amplitude, for example, there are over twenty various permutations of visitor retention reports. While marketing analytics vendors offer some retention reporting, this is where product analytics vendors have placed much more emphasis.
We believe that organizations will start unlocking ways for customers to track the entire customer experience from acquisition to retention to monetization in the future. This is why we have been preaching that marketing and product teams should increase collaboration.
Ecommerce Tracking
Another area in which marketing analytics vendors have emphasized is ecommerce tracking. While product analytics vendors can track products, revenue, carts, etc., there are some super-advanced features that marketing analytics vendors offer that are not available in most product analytics tools. These ecommerce features focus on product merchandising, currency conversion, etc. Features like this were critical when websites began selling products, and it was many years before digital/mobile apps were viewed as viable ecommerce vehicles. But now that more and more online purchases are taking place in mobile apps, most product analytics vendors are ramping up their features to gain parity with marketing analytics vendors.
Self Service vs. Centralized Analysis
When marketing analytics began, the first users of the data was the marketing team that was focused on measuring campaigns. Eventually, as marketing analytics products began tracking content, paths, and funnels more users wanted access to the data. But at the time, data analytics was quite a new field and for a few different reasons, many (not all) organizations continued conducting analysis through a centralized model. In this centralized model, data consumers would submit requests to a centralized analytics team for data and analysis and the centralized team would provide dashboards or reports. Over time, many organizations began teaching casual data consumers how to get their own data and build their own reports, but since many casual data users weren’t proficient in data analysis, they often struggled to “self-serve” when it came to analytics.
In the product analytics world, I have found that there is much more of a slant towards self-service for digital analytics. I attribute this to two primary reasons. First, product analytics came several years after marketing analytics by which time more universities were promoting data literacy. I know that when I went to university, I only took one or two statistics classes, but my kids had done as much by the time they finished high school! This meant that there was a larger workforce of people who understood data and were eager to get their hands on it right around the time product analytics hit the market. Second, the people who were interested in product analytics tended to be a bit more technical that those in marketing analytics. Of course, this isn’t always the case, but more often than not, those building complex digital or mobile apps tend to be programmers or UX folks who understand code and are very comfortable reporting on data related to their products.
Self Service vs. Centralized Instrumentation
Building upon the previous item, another area of differentiation is digital analytics instrumentation (some people refer to this as implementation). Instrumentation is the term for using code to collect data within digital analytics products. In the marketing analytics world, it is very common for marketers to work with development teams to identify their business questions and identify the data points needed to answer them. This information is typically turned into tagging specifications, data layers, and then modeled in tag management systems. This approach started years ago because marketers were not technical enough and didn’t have access to add code to web pages themselves.
But in the world of product analytics, many of those who have questions about the product are the same ones building the products. They are, therefore, often more technical. Therefore, it is common for product teams to add their own code within their products to collect the data they need to analyze and improve the product. While I am sure there are still some aspects of this process that are centralized, many of the teams I talk to prefer to “tag” their own products because it is faster and removes unnecessary bottlenecks. Of course, this can create other data governance problems, which is why, for example, Amplitude acquired an entire data governance software product (Iteratively).
Manual vs. Automated Insights
Another difference I have noticed between marketing and product analytics products is how much they emphasize insight automation. When I have used marketing analytics products, there are amazing ways to slice and dice your data, but there are not a lot of ways that the products automatically identify opportunities for improvement. Most of the popular marketing analytics products have some form of machine learning and AI, but it isn’t pervasive throughout all of the reports.
Product analytics products that I have seen seem to have put more emphasis on embedding machine learning and AI throughout the product. For example, if you build a conversion funnel, products like Amplitude will show you which events and properties contributed to users completing the funnel or dropping off. Marketing analytics products can show you which pages they may have strayed off to, but not the specific events and properties along with detailed statistical significance. The increased use of statistics and automated insights might be a result of product analytics products having come later or the fact that they were built for a more data-savvy generation per the preceding note. Regardless, this is simply another example of where there is a difference in emphasis.
Interoperability
One recent trend in the digital analytics industry is interoperability. Many organizations are now talking about their “MarTech stack” and their “analytics stack.” Over the past few years, organizations have wanted to use “best in breed” products for different portions of their marketing and product needs. In the past, integrating different MarTech vendors or back-end databases was time-consuming and expensive. But nowadays, APIs have made it much easier to send data and cohorts of users between other digital products and databases.
For the most part, marketing analytics vendors have leaned into the “suite” approach (where you use one vendor for most of your MarTech stack), while product analytics vendors have leaned into the “best-in-breed” approach. There are pros and cons to each of these approaches (perhaps another blog post later), but it has been a point of differentiation between marketing and product analytics vendors.
The Future
As you can see, for all the ways that marketing analytics vendors are similar, there are places in which they have emphasized different features and functionality. In most cases where one type of vendor has had a lack of emphasis, it is likely now adding new functionality. As organizations realize that using multiple digital analytics vendors can splinter insights from customer experiences, I have predicted that there will be a push in the future to standardize on one digital analytics platform for both marketing and product teams. Eventually, I see all digital analytics platforms converging on the preceding items such that there is really no way to distinguish between marketing and product analytics vendors. There will likely just be “digital analytics” platforms.
As you might expect, at Amplitude, we believe that the industry trends are moving more towards functionality in product analytics vs. marketing analytics. This belief was one of my reasons for moving from the marketing analytics world to the product analytics world. With the tumultuous changes with privacy (GDPR) and 3rd party cookies, I believe the future will emphasize retention over acquisition. I am also seeing a trend of digital marketers moving to digital product teams.
Whether you agree or disagree with the views expressed in this blog series, I hope that it gave you some things to think about regarding marketing and product analytics. If there are other differences between the two that you think I have missed, please let me know! If you are interested in digging deeper into some of the items above, I have written a freeDigital Analytics Platform Buyer’s Guide that goes into depth on some of these areas.
