Metrica

Analyze each stage of your conversion funnel with detailed multi-step goal segments
4 April, 19:29

In Yandex.Metrica you can now create segments based on each stage of a multi-step goal. This will allow you to study sessions in which a complete conversion did not occur for users. For example, a user added a product to their basket, entered delivery details, but did not complete their order.

Here is what the new feature looks like in the Yandex.Metrica interface:


The “Became last” step condition allows you to select only those sessions in which users completed a particular step and afterwards “fell off”. For example, a payment method was chosen, but the order was not confirmed:

With the “Was fulfilled” step condition, you can create a segment containing all sessions for users that, for example, chose their payment  method and then “fell off”, and also sessions from users who made it further along the conversion funnel, like proceeding to the order confirmation.

In addition, multi-step goal segments can also be used in Session Replay.

You can read more about goal types in the Help section.

No comments
goals,multi-step goals,funnels,segmentation
Download raw data from Yandex.Metrica using the Logs API
18 January, 13:41

We always strive to make web analytics as flexible as possible, which is why Yandex.Metrica allows you to transmit an unlimited amount of data and manage the sampling rate. Now you can also get raw data from Yandex.Metrica for any time period and use it to solve complex analytical tasks, or import it to other analytics systems. Our new program interface, Logs API, makes it possible to download raw data.


How raw data differs from aggregated data

The aggregated data that you see in the Metrica interface or download using the reporting API is calculated for a particular group of sessions. For example, the Time on Site metric might be calculated for all click-throughs from some type of traffic source, all sessions from a certain region, or all sessions from a tablet.

These calculations are all based on raw data: records of individual sessions or pageviews. A table of these records is transmitted using the Logs API. Each record contains useful information from Yandex.Metrica, including detailed info on ad performance in Yandex.Direct and granular ecommerce data, the user's country and city, and various technical information about the session (the browser and mobile phone model used, etc.)


Why you may need raw data

It is, of course, easier to manage aggregated data because you see statistics for various performance indicators and all you have to do is draw conclusions based on them. Raw data, however, is essential to get new statistics that aren't available in the reports. 

Here are some examples of how to use non-aggregated data:
 

Create complex sales funnels

To study the flow leading to a sale in detail, you can track the history of click-throughs to your site for each user separately and highlight patterns that are important for your business. For example, you might want to study the intervals between sessions during which users complete target actions, or what channels usually bring customers in at each stage of the funnel.


Build custom attribution models

There are three standard attribution models in Yandex.Metrica: first, last, or last significant (non-direct) click. By working with raw data, you can create other types of models and analyze in detail how different marketing channels impact the conversion rate. For example, you might track how banner ads affect sales in cases where display ads brought users to your site at least once, but weren't the first or the last traffic source.


Combine data from different sources

Raw Yandex.Metrica data can be added to your data from other systems. For example, you can bring all your ad spending statistics together, or supplement Yandex.Metrica data with data from your CRM.


Monitor discrepancies in statistics

Sometimes figures in other analytics systems don't match Yandex.Metrica's numbers. This is usually due to different calculation methods: by analyzing raw logs, you can figure out how each system processes data and choose the approach that better serves your tasks. 


How to work with the Logs API

Raw data is transmitted in the standard tsv format; this type of file can easily be imported into most database management systems. This includes ClickHouse, a free open-source solution that powers Yandex.Metrica itself. ClickHouse can process complex requests in real-time, is easily configured, and doesn't require large computational resources. Furthermore, fresh data can be automatically downloaded to ClickHouse using a script developed by the Yandex.Metrica team. 

Logs API documentation, a detailed description of the data scheme, and the script for downloading data to ClickHouse are available on the technologies site.
 

1 comment
logs api,raw data
Webvisor 2.0 is coming soon
16 January, 12:57

Webvisor, our session replay tool, became part of Yandex.Metrica five years ago. Since then the internet has changed a lot with the appearance of new technologies for creating websites, while mobile phones have become a significant source of traffic and conversions. To tackle these new challenges, Yandex.Metrica is creating Webvisor 2.0, which will have improved precision in recording all the details of sessions. You will also be able to try out the new Webvisor in the upcoming beta.


What’s changing in the new Webvisor?

The current version of Webvisor has several options for recording and playback. The quality of these recordings is not only influenced by these options, but also by the specific features of a site, and there are some types of dynamic content on a site that the current version of Webvisor cannot record.

The new version of Webvisor will function without the need for any additional options – you will be able to turn it on, or turn it off. The accuracy of the recording will no longer depend on the specifics of the site, and Webvisor 2.0 will always record the content seen by the user. As with the current version, you will still be able to turn off the recording of keystrokes in certain fields.


What can the new Webvisor record?

Dynamically-changing pages

Webvisor 2.0 will correctly record content that appears as it happens while a user is viewing a page. For example, product offers in an online store’s search results that are shuffled when a user scrolls down a page and is then presented with new offers based on those that the user just recently viewed. Another example would be individual collections of articles on a news site which are created based on what sort of material a user has previously read.


Plugin content

Certain types of content are created by third-party plugins which can be found on a site. They may be things like chat windows to contact support or recommendation systems that select products for users to view.

The current version of Webvisor does not record the exact content seen by a user in such blocks on a site. However, Webvisor 2.0 will always be able to correctly reproduce these elements in playback. The same will also apply to ad blocks, as the new version of Webvisor will record them as accurately as possible. With the new Webvisor you will be able to assess the impact of these third-party plugins, and track how ads affect user behavior.


Mobile traffic

Sessions from mobile devices will be recorded with improved precision, as the new Webvisor will be able to catch transitions from the desktop version of a site to its mobile version that do not require a page to be reloaded. In addition, webpages will be correctly displayed during playback when a mobile device is rotated. Another useful update is the addition of a mobile device’s screen contours to the recording of a session, which will make it easier to understand what is happening.


How to take part in testing

Send in your email address and counter number via this form to try out the new version of Webvisor. You will be contacted when Webvisor 2.0 is ready for beta testing.

Beta testing is closed. Thanks to all who joined our beta testing team! If you weren't able to try the beta version, don't feel down: the new Webvisor is on its way.

Please note: the Webvisor tool has been renamed to Session Replay.

Learn more about behavior analytics tools in Yandex.Metrica.

1 comment
webvisor,behavioral analytics
Meet Yandex.Metrica at the Superweek Conference in Mumbai
21 December 2016, 19:54

Join us at the Superweek Conference on January 5-7 in Mumbai, India. This annual event brings together digital analysts from all over the world so that they can share experiences and discuss the latest trends.

The head of Yandex.Metrica, Viktor Tarnavskii, will talk about raw data and its implementation in a sophisticated, custom-made attribution model for one of the largest online DIY retailers in Russia.

Viktor will demonstrate how to use raw data to trace the path-to-purchase and distill the most common user behavior patterns, in order to create an algorithm that calculates how likely each user is to buy something. This way, you can effectively build a custom behavior-based attribution model and reallocate ad budgets to the best performing channels.

Catch Viktor to ask him any questions about Yandex.Metrica, or simply share your thoughts on all things web analytics. See you in Mumbai!

1 comment
events
Analyze AMP sites with Yandex.Metrica
1 December 2016, 18:15

Now you can track AMP sites using Yandex.Metrica. AMP (Accelerated Mobile Pages) is a special html format that lets you load mobile pages significantly faster.

AMP is geared primarily toward the needs of publishers: for news sites and blogs, it’s essential that content is mobile-friendly and downloads in a flash.  That’s why in the AMP-compatible counter code, we now support a few attributes that will come in handy when measuring content effectiveness:

scroll — tracks how far down a page is scrolled.

visible — marks what parts of a page or what separate elements were in the visible part of the screen.

timer — lets you work with precise bounce rates. By default, a session lasting less than 15 seconds is considered a bounce, but you can set a different, custom threshold.

You can also set goals for AMP sites and send session parameters. Some functions, such as Webvisor Target call, and Ecommerce reports are not available due to some technical restrictions of this format. Detailed instructions on how to add counter code to an AMP-site can be found in the Help section.
 

No comments
AMP
Yandex.Metrica mobile app: fresh stats on the go
12 September 2016, 16:15

The brand new Yandex.Metrica mobile app for iOS and Android allows you to quickly check the latest traffic numbers and trends.

We have outfitted the app with those features most convenient to have on a smartphone:

Dashboard. Customize it to meet your needs — choose the widgets you need and arrange them as you see fit. Tap any widget to see a more detailed report.


The reports you need. The mobile version features practically all the reports available in the desktop version: source, traffic, audience, and Ecommerce, among others. You can choose the accuracy level (sampling), add statistics by goal, and switch attribution models.


Special “Sessions” section. See a list of all site visits and drill down into each session to find out its duration, source, region, and many other details.



Your own desktop segments. All the segments you save in the desktop version of Yandex.Metrica are available in the app.

Large graphics. View any report in landscape view. Tap a point in the graph to see its value.

Various access levels. View statistics as a counter owner, account representative, or guest.

You can download the app in Google Play or the AppStore.

We plan to add more functions to make Yandex.Metrica easier to use while you’re on the move. Please send us your suggestions or features you’d like to see added to the mobile app.

No comments
mobile app
User parameters: answering your questions
12 August 2016, 19:20

In wake of our user parameters workshop, we put together a list of the most frequent questions we received concerning the two ways to transfer data: online and offline.


Settings

— Which way is better — online or offline?

It depends on the type of data you want to work with. Online data transfer works best for information that only "lives" online and doesn't need to be stored in a CRM (such as certain aspects of how visitors use your website). In some cases though, it's still useful to note this "online" information in your own database and then send it to Metrica from there.

For example, if customers can get a discount card on your site, you'll want to note that certain customers have this card in your database.

The two methods also differ in speed. Offline uploading lets you add data for visitors that already have UserIDs/ClientIDs faster: parameters will update immediately when you upload the current file. By contrast, you will have to wait for the customer's next visit to your site to send data using the userParams method.

If necessary, you can transfer data using both online and offline means.


— What's better, a UserID or a ClientID?

This depends on whether or not you have your own unique customer IDs. If you do, then it's simpler to use UserIDs and not involve an extra ID system.


— Can I use different ID types simultaneously for the UserID (such as username and social network referrer)?

You can only choose one ID type for the UserID. Otherwise different UserIDs will be transfered to Metrica for the same visitor and that individual's parameters will be matched with several different visitors.


Usage

— I get a "matching error" when I try to upload my file. What should I do?

A matching error means that you either haven't added the code that calls the setUserID or getClientID methods to your site or this code is not functioning correctly. You might also be getting this error because no visitors that you transfer UserID's for or get ClientID's from have visited your site yet.


— Is it necessary to get a 100% client match when uploading a file?

In actual practice, 100% matching doesn't happen: sometimes a customer's data doesn't "stick together" due to small technical kinks (for example, like when a visitor leaves a site before the counter code loads).

If you've got any other questions about user parameters, just ask away in the comments – we'll be happy to help.

No comments
user parameters
Workshop: transmitting user parameters offline
11 August 2016, 16:10

Let's continue our discussion about working with user parameters. Last time we went into detail about how to transmit data online and in this article we will talk about uploading it offline. This method lets you add information that you already have in your database (such as customer income or loyalty status) to your reports.

In order for Metrica to determine which visitor should have these new attributes, data from your base needs to be linked to Metrica data by assigning them the same ID. This can be done either by sending Metrica your own customer IDs (UserID) or by entering unique visitor numbers from Metrica (ClientID) into your CRM.


Matching based on UserID if you have your own customer identifiers

Stage 1. Teach Metrica to recognize customers

To start transmitting your own authorized user IDs (UserID) to Metrica, you need to add code on your site that will insert these IDs into the setUserID method:

yaCounterXXXXXX.setUserID(<UserID>)

UserIDs will not display in reports; they are saved in the Metrica database as keys that allow Metrica visitors and your CRM customers to be matched. Every time an authorized visitor visits your site, Metrica receives a command to "remember" that visitor using their UserID.

This match will be made for all your registered visitors after they visit your site at least once under their username. This process may take some time: it depends on how often your customers return to your site.

UserID can be sent for non-authorized visitors as well. You can also get unique IDs from "tagged" links that you send to your customers via email or social network referrers. Discount card numbers or promo codes that the visitor enters on your site can also be used as UserIDs.
 

Stage 2. Upload data

After sending Metrica enough UserIDs, you will need to prepare a file with the customer attributes that you want to add to your reports. This table should be in csv format with three columns. The first contains UserIDs, which will be used as keys to link data in your file to Metrica data. The second will contain parameter names and the third is for parameter values.

Here is how that type of file looks:

To send this file to Metrica, go to the Upload Data tab in the counter settings. Don't forget to choose the file type  — UserId:

After the file is processed, you will see this notification in the interface:

Status: Completed (80% match). This means that the UserIDs you transmitted were found in Metrica for 80% of the customers in your file. Usually the data can not by completely matched up because not all customers visited your site, which means that you haven't transmitted their UserIDs yet, and Metrica doesn't know which visitors it should assign the attributes in your table to. So parameters will only be added for the 80% of visitors that were matched. It's important to keep this in mind when you look at your report data.

☞ Metrica can store up to 1000 parameters for a single visitor.


Matching by ClientID when you don't have your own visitor IDs

A ClientID is a number that Metrica assigns to every visitor. It can be used as a key to link data if your site doesn't have its own identification system or if customers rarely register online (because, for example, they place orders by phone).
    
To get ClientIDs from Metrica, add code that calls the getClientID method to your site and record the value you get to your CRM:

<ClientID> = yaCounterXXXXXX.getClientID()

After some time has passed and enough visitors have been to your site and gotten ClientIDs, a csv table of customer attributes can be generated. It will look the same as in the UserID example, only this time the first column will use ClientIDs as keys that match visitors. And you need to choose the ClientID file type when you upload a table to Metrica.


How to update or delete uploaded data

All you have to do for reports to start displaying new parameter values is upload a current file. If you want to delete data, you need to go to the same data-upload menu, select Delete and transmit a file with empty parameter values:

Uploading this type of file doesn't set parameter values to zero; it deletes them. In other words, if you transmitted the number of purchases per client and then uploaded an empty file, the offline-purchase parameter would just disappear from your reports rather than have a zero value.


Is it better to transmit visitor parameters online or offline?

With the userParams method, it makes sense to send data that only relates to online behavior and doesn't need to be stored in your own database. This way also works for internet publications or blogs that don't have CRMs.

The two approaches also differ by the speed of data updates in reports. When you get the setUserID or getClientID method up and running and the majority of your customers have visited your site at least once, new data will show up right away in reports as soon as you upload a current file (rather than waiting until the customer returns to your site.

You can find answers to frequently asked questions regarding both ways to work with visitor parameters in this article.

No comments
user parameters
Workshop. User parameters: online data transfer
28 July 2016, 19:05

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:

yaCounterXXXXXX.userParams({     
            vip_status: true
});

And here's how the method will look when an ordinary customer logs in to the site:


yaCounterXXXXXX.userParams({
            vip_status: false
});

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.


yaCounterXXXXXX.userParams({
            status: "client"
});


yaCounterXXXXXX.userParams({
             status: "partner"
});

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.


yaCounterXXXXXX.userParams({
            pet: "dog"
});


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:


yaCounterXXXXXX.userParams({
            delivery: "Arbat"
});

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.

No comments
user parameters
User parameters
14 June 2016, 11:40

Yandex.Metrica now has a new feature — user parameters — which allows you to analyze your audience more deeply by assigning your own customized attributes to your site’s users. Moreover, you can do this both during the session and after its completion.

A similar feature has been available for some time in Yandex.Metrica alongside the information it collects on its own about sessions. This feature allows customized data sets in the form of session parameters to be used to build reports.

Yet there are some types of data to which only you as the owner of your business have access. Examples include information provided by users at the time of their registration, or client characteristics from your CRM system. The data from your sources is information that you yourself deem valuable for your specific business, and unlike session parameters, it contains attributes of actual users. Now it’s possible to transmit this data to Yandex.Metrica and use it for audience analysis with the help of the new “User parameters” function.

Also, unlike “Session parameters,” user data need not be taken during the actual session—you can collect, prepare and load it into Yandex.Metrica later, linking it to your site’s users with the help of IDs that either Yandex.Metrica assigns (ClientID) or that you assign (UserID).

You can send data, for example, related to whether a user has a discount card for your store. Using new segmentation, you can compare these and other users’ behavior on your site in reports.

Of course, once you’ve created a segment with applied user parameters, you can then launch a special retargeting campaign in Yandex.Direct. If you know, for example, that many of your clients were born in July, you can enter this information into Yandex.Metrica, create a segment and offer users in this segment a special birthday discount.

Being able to send up to 1000 different parameters for one user opens up great possibilities when working this this data. Learn more about user parameters and examples of data transfers in the Help section.

No comments
New segmentation
30 May 2016, 16:25

We've updated our segmentation capabilities to make this tool even more useful.

Whereas previously you could segment by events for a specific session, now you can also incorporate data from that unique user's previous sessions, as well as information that Yandex.Metrica has gathered about their characteristics. In other words, the new segmentation capabilities let you work with the user's entire session history saved on Metrica.

For example, you can select sessions where a user achieves a particular goal and simultaneously set a condition that they viewed the contacts page during previous sessions. Or, if you're set up to send e-commerce data, then you can select only those visitors that bought more than a set amount of products over your site's entire history.

The new segmentation capabilities also let you add several conditions of a single type. For example, you can select sessions where one of several promo pages was viewed (the first "URL view" condition) and one of two order pages was visited - "/order/" or "/one-click-order/" (the second "URL view" condition).

Additionally, you can select the time interval when the condition should have been fulfilled when you set the visitor condition (and this interval can differ from the reporting interval).

And finally, new segments can still be used in retargeting campaigns in Yandex.Direct, as usual. To learn more about our new segmentation capabilities and see additional examples of how they work, visit our Help section.

No comments
segmentation
Why can't the traffic source be determined?
18 May 2016, 11:10

More and more sites are switching to the secure https protocol and this has become an inconvenient fact for many website owners whose sites are still running on http. Specifically, sites who have not yet switched to https are seeing higher percents of direct visits.

From the technical p.o.v., "direct visits" are those where the user's browser doesn't send the Referer technical field. Usually this field contains the URL of the previous page that the user visited before landing at your site. If this field is absent, it means that there was no previous page because, for example, the visitor entered your page address manually into the search bar.

But the case is not always so simple. The W3C (World Wide Web Consortium), which develops internet standards, published a document on Referrer Policy that gives recommendations on when to send the Referer field depending on what types of sites the visitor clicks between. Though this document has not been definitively approved, the majority of up-to-date browsers already support the recommendations contained in it.

This document makes the following prescriptions: that the referrer is sent when a visitor goes from http to any site type and when they click-through from https to https, and only not sent when they click-through from https to http. These recommendations are completely logical: if you leave the safe haven of an https site, the browser will not send the address of the last page you visited over open (unencrypted) channels.

In practice, this is what it means for website owners: if your site is still running on http, you won't see a traffic source if that source uses https.

The best solution in this situation is to switch your site over to the secure protocol. Now you can get a free encryption certificate thanks to Let's Encrypt, a non-profit certification center that supports many of the main players in the online industry.

And if you're on the other side of the problem (i.e. you're the owner of a secure internet-resource but want the Referer field to be sent when visitors go to other sites from yours even if those sites are not protected), then there is also a solution for you. You can mark up the pages of your site that lead to non-secure resources using a special meta referrer. You can read more about these various methods in the Referrer Policy document under the Referrer Policy Delivery section. According to the "Can I use" project's data, this type of link markup is already supported by over half of browsers in use.

No comments
https,http,not determined
Heat maps for groups of pages
28 April 2016, 12:35

Now you can display heat maps for groups of similar pages (rather than just for individual pages).

Say you want to know how visitors interact with your product pages, but you have a lot of different products on your site and each individual product page gets too few clicks to do an analysis. Now you can gather clicks from all your product pages and display them as one page.

Click to enlarge:

A page group can be set as a a simple mask (http://shop.yandex.ru/catalog/*) or a regular expression.

You can work with groups of pages for all types of heat maps: click maps, link maps, and scroll maps.

No comments
heat maps
The new Yandex.Metrica report includes indication of ad blockers
18 April 2016, 14:00

Metrica has started to collect information about the use of ad blockers among website users. We don't determine what specific blocking program is used, but rather whether or not one is present.

The new report is available in the Technology section. Ad blocking data can also serve as a segmentation criterion: you can compare how users who viewed your ad behaved in comparison with those who didn't.

The percentage of users with ad blockers can also be used as a metric. For example, if you display this figure in a separate column of any report, you can find out how popular ad blockers are in relation to specific browsers or traffic sources.

According to our data, approximately 9.6% of users currently have ad blockers installed. This percentage can vary significantly, however, depending on the website.

For more information about the new report, read the help section.

No comments
ad blockers