Clever Geek Handbook

How to build an e-commerce layout process to get all the data you need

Introduction



Anyone who has used Google Analytics or similar web analytics systems knows how convenient they are for tracking and analyzing online store performance data. The main convenience is that in these web analytics systems there is a pre-designed data structure for tracking - E-commerce or E-commerce. This makes it possible not to think from scratch every time in what form to collect data, and as quickly as possible to switch to using data to optimize efficiency.



By transmitting data in the electronic commerce structure, you can answer the questions which products are more often added or removed from the basket, which products cards are viewed more often and, of course, which products are most often bought. All these data can be obtained by categories, brands, names and articles of goods. You can transfer additional data on the characteristics of the goods and get the opportunity to build a report on the best-selling goods by color, weight or size. Or, build a report on the most clickable banners on the site or product positions in the catalog and any product blocks on the site.



However, often collecting e-commerce data becomes a very difficult task. It seems that there is nothing complicated: we give a qualified developer or development team a link to documentation, for example, Google Analytics e-commerce , and optionally a link to Google Analytics e-commerce demo , and after a while we get the result. In our practice, this approach has never worked, either with cool development teams supported by business analysts, or with a freelancer with the nickname "Potato" and an avatar with a banana. We can confidently say that the problem is not in people and their qualifications, but in the process.



This article will focus on how to build an effective process for integrating Google Analytics e-commerce into a large project. By a large project, we mean a site of any size that at least such a team works with: web analytics, frontend and backend developers, business analyst and product owner. And, of course, this project needs web analytics data to make decisions, and not just to close the task from its development backlog.



Disclaimer



Everything described in the article is exclusively our experience. If you did it differently, it just means that you did it differently.



Many, even large players in the e-commerce market, have not succeeded so far. E-commerce data is transmitted at the front, so it can be easily checked in the console or in GET requests like https://www.google-analytics.com/r/collect/… , or a little more conveniently with the Google Analytics Debugger extension for Google Chrome . Therefore, you can quickly check which of the TOP-100 of the largest online stores in Russia, according to DataInsight, all data is tracked.



Stage one: identify stakeholders and collect their data requirements



The list of interested parties may vary depending on the structure of the company. As a rule, the main users of web analytics systems are business representatives, a product team and product analytics.



1. Business representatives



Depending on the data used, web analytics systems of business representatives can be divided into several parts:

  1. Internet marketers and specialists in various traffic channels are those who use web analytics systems to analyze and optimize traffic. This group has no specific requirements for electronic commerce data. It is enough that transaction and income data will be transmitted.
  2. Category managers and purchases - those who are fundamental to detailing data on goods. The main requirement of this group is the ability to obtain key indicators of electronic commerce by product characteristics.
  3. The managers of individual projects or areas are usually very universal in their tasks, therefore they combine the requirements of the previous two groups.


2. Product team



There can be different roles in a product team: developers, business analysts, project managers, designers, product owners. But everyone has one task: to make the product better. And if possible, make improvements, understanding not only their priorities, but also the frequency of using one or another functional.



This is the main requirement for data analytics systems. But do not forget that after receiving the data, the product team generates and tests hypotheses in the framework of A / B tests.



3. Product analytics (or web analytics)



The team responsible for the integrity and consistency of these web analytics systems needed to make a product decision. The task of product analysts in this process is data quality. In addition, they understand how Google Analytics collects and processes data. Therefore, it is they who must collect all the requirements from the rest of the teams.



Usually all sides of the process are very different tasks and, accordingly, use different data in web analytics systems. The final decision should meet the requirements of all parties, but they hardly overlap. Therefore, there are no problems at this stage.



At the end of this process, you must clearly understand:

  1. What user parameters and indicators need to be created to solve the tasks of category managers.
  2. What key indicators are needed for the product team and where is it impossible and will have to use data from other accounting systems.


Stage two: discussion of data implementation with the product team



After the requirements for the transmitted data are formulated, it is necessary to return to the product team and discuss with business analysts from which sources all the necessary data will be transmitted.

For example, most likely on some pages it is impossible to collect some of the characteristics of goods needed by category managers from the front. Or on some pages for this you need to make a separate request to the database. If after discussion you understand that such difficulties arise, it is worth taking the path of importing most of the data on goods into Google Analytics directly from the database with data on goods. And, accordingly, at the front, transmit a minimum of information on goods: name, cost, membership in the list of goods and position in the list.



Stage Three: Description of the Data Transfer Solution



Based on the collected requirements, it is necessary to formulate a description of how e-commerce data will be collected from the site in Google Analytics. The options may be different, we will describe those that we most often encounter with their pros and cons. This is the most important stage in the implementation of electronic commerce, since it depends on it how quickly it will be possible to proceed to the stage of using data.



Put the Google Analytics code directly into the site code



The easiest and most inconvenient option is that developers put the Google Analytics code in the site code and, on their side, implement the transfer of all electronic commerce data.

Most often, such a decision comes in teams with a strong development due to the feeling that the data will be consistent - the developers are never mistaken. Unfortunately, they are also mistaken, but with such an implementation everything is tied only to developers and their release cycle. Any changes are possible only on the development side, web analytics are only needed to use the data.



Pluses of this option:





Cons of this option:





In general, we do not recommend using this option to anyone and never.



Put on the site Google Tag Manager and transfer data to dataLayer



In our experience, it is best to start with a standard e-commerce dataLayer and gradually enrich it with user-defined parameters and metrics. At the same time, dataLayer data enrichment should be based on the requirements of business data users.



In no case do not recommend the first step to invent or copy from someone dataLayer, which will immediately contain all the data that comes to your mind. Often, in pursuit of the speed of implementation of electronic commerce markup, they prepare a large universal task for developers to transfer all possible data to a dataLayer in a single structure, but with the same triggers. There are several problems with this implementation. First, in the pursuit of versatility, business requirements and technical storage infrastructure features are not taken into account. Secondly, when using the same triggers for sending data, web analytics lose the ability to easily change data in Google Tag Manager, they also have to operate with universal data and triggers.



In any version of this approach, the greatest burden falls on the development team. It is enough for web analysts to read and transmit data in approximately the form in which they are. But there is already an opportunity to handle data a little more flexibly than in the case of markup without using Google Tag Manager.



What problems may arise in this implementation? Any error in sending data from the site makes it difficult to change the data on the Google Tag Manager side. For example, often there is a problem with the fact that the Google Analytics server accepts requests no more than 8 kb. And when sending data on product impressions in product lists, the request is much larger. It’s not easy for web analysts to reassemble the data into Google Tag Manager and send it to Google Analytics. And the root of this problem is that the structure of the data sent does not imply this.



Pluses of this option:





Cons of this option:





Put on the site Google Tag Manager and transfer data to js-object



In our experience, this is the most convenient and flexible option. It consists in the fact that the developers implement the transfer of all necessary data to a certain js-object with a structure similar to the structure of a regular dataLayer e-commerce. With each user action on the front, which is associated with the actions of electronic commerce, the data in the js-object is changed and a push is sent to the dataLayer, which indicates what change has occurred (for example, an item has been added to the cart).



This implementation gives web analytics a set of triggers for each important user action and the ability to collect data from the js object for Google Analytics e-commerce data by creating a separate HTML tag or variable in Google Tag Manager.



You can go even further and develop this logic. Create a standard structure for a js-object with data, your own version of a tag manager and start a startup. The main thing is to follow the business requirements for the data collected, and implementation details may vary.



Pluses of this option:



generated by the backend, without load on the front.



Cons of this option:







Put Google Tag Manager on the site and collect data with js tags from the front



With the appropriate qualifications of web analytics or connecting the front-end to the team of web analytics, you can collect all the necessary data with HTML tags and Google Tag Manager variables.



This is the fastest way to implement e-commerce markup. The web analyst knows what data and in what form should be transmitted, and he writes the code that sends this data. By reducing the number of participants in the process, the implementation speed is maximum. It is clear that this option imposes great restrictions on the qualifications of the contractor.



Another limitation in using this approach may be the site code itself. The greatest difficulties can be with projects that use frameworks such as Angular or React. In this case, many changes to the site’s code will affect the Google Tag Manager HTML tag code and result in data not being collected properly. It is difficult to defeat, but it is possible. For example, supplementing layout elements critical for layout, with separate identifiers, which will not change and will be checked by automatic tests with any release.



In order to reduce the load on web analysts and reduce the time for layout, you can additionally connect front-end renders and make a combination of this and the previous layout options. It is necessary to supplement the site layout with data-attributes, in which all the data necessary for transmission in the framework of electronic commerce will be recorded. For example, in the div with the product in the catalog, you need to add data attributes with the product category, its name, article number, value, and so on. This will allow web analysts to collect data not from the entire layout, but to access specific data attributes that will be known in advance.



It is important to remember that even in this embodiment, when the team of web analysts does the maximum work, it is necessary to create at least minimal markup documentation. This will allow you to quickly figure out how data is collected at any time and, if necessary, make changes to the markup code.



From experience, web analysts often forget to add the necessary checks for variable values ​​or constructs like try ... catch in the code of their scripts. Therefore, after implementing markup in this way, it is worthwhile to additionally check the correctness of all scripts.



Pluses of this option:





Cons of this option:





Regardless of which markup implementation option you choose, remember that the task is not to immediately begin to collect all the possible data. And to start collecting the correct data as soon as possible so that the business begins to apply them. And over time, develop the direction of data collection. The worst thing that can be done at this stage is to go headlong into the implementation of data collection for a long time, without the ability to immediately use them.



The fourth stage: preparing a guide for developers



Almost all of the markup implementation options proposed at the previous stage involve the involvement of developers. In order to simplify their work a bit and reduce development time, it is worth creating a document or guide with a description of how the data should be transmitted from the site.



What should be described in the guide:



1. Features of data collection





2. What are the minimum fields that should be passed on the key entities of data collection





3. When and in what form should data be transmitted for each e-commerce activity of Google Analytics.



4. When and in what form should the data on other user actions on the site be transmitted.



After the guide is formulated, it must be discussed with the development team, collect all questions, inaccuracies and immediately correct in the document. Since in the future this particular document will be the main one in the process of markup implementation.



Fifth stage: markup implementation and subsequent review



After the implementation of each part of the markup by the developers, it is necessary to verify the correctness of the transmitted data. At first, this process cannot yet be given to testers; they must be connected after the web analyst finally accepts the corresponding part of the markup.



The audit should contain two stages: qualitative and quantitative. The qualitative stage is to verify the transmitted data by the web analytics, which on the preprod checks in its browser how the data is transmitted on standard pages and user actions. The task of this check is to catch obvious errors and roll out the already verified version to the product. The next step is a quantitative check. This is a validation of the markup according to Google Analytics. It allows you to catch less obvious errors and markup bugs on a large data sample.



After conducting checks, the data can be transferred to business customers for use. And after that, with a team of testers, prepare a set of cases for checking the markup. So that new releases do not break what has already been tested and works.



Conclusion



Very often the most important thing is missed during the markup process. The markup is needed in order to use its result - data in web analytics systems. The markup process is important, but only in order to quickly reach the finals and collect fewer errors.



I hope this article helps to avoid some errors and implement Google Analytics e-commerce markup as quickly as possible.


More articles:


All Articles