By default, Yandex.Metrica gathers a lot of data about people who visit your site: their gender, interests, session history, and other information. And it's probably the case that you, as a business owner, have a lot of other useful information about your customers: whether or not they have loyalty cards, what car they drive, when their policy expires, etc. If this information can be combined with the data already available in reports, you can highlight all kinds of different groups of visitors for analysis and ad targeting. For example, you can compare how customers with discount cards behave versus those without them. Or you can offer a special discount to customers with cards who haven't visited your site in a while.
To add your own customer data to reports, you must transfer your visitor parameters to Metrica: you can either send them online (while the visitor is on the site) or offline by uploading a csv file.
We'll discuss both methods in detail over two article-workshops, starting with online data transfer. This method allows you to send both events that occur as the visitor interacts with the site, and data that already exists in your database to Metrica.
Transferring data from your company database to Metrica reports
Let's use an internet store that has two types of customers (ordinary and VIP) as an example. Customer status data is saved in the company's own database. After a visitor signs up on the site, every page will display their name/username instead of the generic Log In link. If applicable, the visitor’s VIP status will appear next to their name, for example: Vasily/VIP.
To send customer status to Metrica, you need to add code that will call up the special userParams method on all your site pages. This method will transfer data about status.
The method for these "special" customers will look like this:
And here's how the method will look when an ordinary customer logs in to the site:
Nothing needs to be configured in the Metrica interface. This new parameter will automatically become available in any report as a segmentation condition as soon as the parameter value is transferred to Metrica at least once:
You can check that data is being transferred correctly in the special Visitor Parameters report (in the Contents sections):
If an ordinary customer gets a special status, then the next time they log in to the site the userParams method will send the changed data to Metrica. Furthermore, the new status will apply to that user's whole session history as if they were a VIP customer all along.
Online events: how to send only relevant data
Using the userParams method, you can transfer any data from your own database that displays in the visitor's browser. This method lets you manage data that appears as the visitor interacts with your site (for example, when they click on something). Please note, by the way, that this data may refer to a particular visitor or a concrete session, and be careful not to confuse the two. If a session event is transfered as a visitor parameter, reports will gather together the wrong data. To prevent this, it's useful to keep data levels in mind when you work with Metrica.
Basic level refers to pageviews. The next level refers to sessions (i.e. several pageviews made by one visitor at one time). Lastly, the visitor level comprises all sessions of one Metrica visitor across their entire history of sessions.
Every data level has its own attributes. For pageviews, we know the particular pages that were viewed and where the visitor came from. For session characteristics, we know date/time, length, geography, browser, and other data. And in regards to Metrica visitors, we know their gender, major interests, date of first session, and time since last session, among other things.
For sessions and visitors, you can transfer other parameters you have (and again, it's important not to mix up your session and visitor parameters).Visitor properties differ from pageview and session properties in that they are not related to time.For example, the Send Feedback event is attributed to a specific session, because the user could only submit that feedback once over the entire history of sessions. Therefore, it doesn't make sense to make this event a visitor attribute because the reports would then show that that visitor submitted feedback during every individual session.
To compare the behavior of users who have left feedback at least once with those who have never sent feedback, you need to set up |session parameters| so that this event is sent to Metrica, and then create the |corresponding segments|.The user parameter, on the other hand, should only transmit characteristics that don't change from session to session. For example, customer type — Retail or Partner.
Examples of event transferring
1. If we continue with the example of distinguishing retail customers from partners, we’ll see that this can be done by determining if they used the Log In For Customers or the Log In for Partners. As is the case when you transfer data from your own database, you have to add special code to your webpage. This time though, code will be checked by a referrer (which reveals what link the visitor used to get to the log in page) and the corresponding value will be transferred in the userParams field.
2. Let's say that there is an e-journal for pet enthusiasts and visitors can indicate what type of pet they have at registration. In this case, data can be taken from the appropriate field of the form that the visitor fills out.
3. Suppose that your company delivers food and you want to analyze how much revenue you take in from visitors in relation to what area of the city they're from. In doing so, we know that customers usually order delivery to the same address, so we can put this parameter on the visitor level:
We would be interested in hearing of other examples you have of transferring customized visitor parameters. Please share your experience in the comments section. As always, feel free to leave questions as well.
In the next workshop we'll get into more detail about uploading data offline and address some FAQs concerning both means of working with user parameters.