Tale of traffic

As we promised, we are starting a series of posts about the technologies and techniques that are used in our company. We would like to start with an internal product called OMPW - Oversun Media Players Wizard - user support assistant. This system is used by almost all departments of our company and can do a lot.

OMPW consists of heaps of modules that allow us to purchase traffic, control its quality, experiment with landing pages, keep track of users and their game events, build reports and keep an audit of gameplay.

Today we will deal with the procurement module and traffic quality assessment. This part turned out to be quite voluminous, so we recommend stocking up with desire, time and utmost attention. We tried to make the material the easiest to master, but the theory cannot do without definitions and terms. It should be interesting.

What are you looking at when you twist a bottle of yogurt in your hands from the refrigerated storefront? At the date of packaging and production, shelf life, calorie, beneficial properties and the presence of vitamins. If you summarize, then you study the consumer properties of the product and compare them with the price. Even if you do not take into account the price of 1 bottle, with 100% probability you will begin to do this with the wholesale purchase of hundreds of thousands of bottles.
')
The same situation with traffic. No one buys it without evaluating the effectiveness of the money spent - it would be unwise. Usually, test purchases are made for a couple of thousand visitors and, if the price-quality ratio is acceptable, bulk purchases begin with constant monitoring of indicators.

What do we need to know about games?

Before turning to the traffic, we need to consider the player's life path. And we begin with the simplest - with the events. An event is what happens in the life of an observed object. In our case, this is something that happened with the player: visiting the site, registering, creating a game character, taking a quest, fighting or raising a level.

Note: in the text you will find many names of events. By internal agreement, the name of the event is formed from two lines connected by a dot. The first line denotes the action object (in programming, a class or an object). The second line indicates the action that is performed on an object (in terms of programming, a method, a member function).
Examples of event names: "quest.get", "quest.cancel".

Almost always the event has parameters. For example, “taking a quest” is always accompanied by a quest identifier, a battle — an identifier of a battle and a set of opponents, and a level increase — a level number. Events that may occur more than once, it is customary to supplement the parameter "event number". Everything is just like in life: “When I got married for the third time ...”, “My first computer was ...”, “When they called me the tenth time in a day ...”.

The set “event + parameters” we call “point”, since there is always only one such set in the player’s life. The player can not pass through the point twice. All points are stored in the database of the game project and represent the player's history (log).

Traffic classification

In order to begin to understand the criteria for estimating traffic, we need to familiarize ourselves with the traffic classification (according to our version).
According to the source, traffic is divided into:

• banner;
• pop-up - pop-ups;
• click under - open pages in the background;
• teaser - graphic blocks with a small description;
• contextual - contextual advertising;
• organic - custom posts and reviews;
• social - from social networks;
• traffic exchanges - traffic is collected from various sources;
• arbitrage traffic - “bought where it is cheaper, sold it much more expensive”.

The rest of the traffic lies outside our interests, because in most cases, he has no legal basis.

By type of payment traffic happens:

• with a one-time payment for the publication of the material - organic traffic;
• with the rental of advertising space - banner or organic traffic;
• pay-per-view advertising material (PPV - Pay Per View) - banner traffic;
• with payment for each visitor (PPC - Pay Per Click) - all types of sources;
• with pay per action (PPA - Pay Per Action) - all types of sources;
• with the deduction of interest on payments made by the player (referral system) - all types of sources.

Various combinations of payment types are also possible. For example, “10 rubles per 1,000 banner impressions + 15 rubles per 100 clicks to the site + 20 rubles per 100 registrations”.

Traffic quality assessment

Obviously, it is impossible to work out a uniform traffic purchase plan for all partners. Therefore, with each supplier, the work goes according to its rules, and the assessment of traffic efficiency is considered “in parrots”.

What does it mean? Game design says that a person can be considered “sat down on a game” if he spent half an hour in it, which roughly corresponds to the second level of the player. Thus, it will be most advantageous to pay for reaching the second level, which means that the user’s cost should be considered exactly at this point. Most often, this point is called "effective registration."

In affiliate programs for gaming traffic, you can often see that the payment is made "for registration", "for effective registration" and "for the active player" - the classic manifestations of the PPA. Everything is clear with “registration”, we have already dealt with “effective registration”, but everything is difficult with “active player”. The fact is that no one but the game project knows what an “active player” is. This is done on purpose, to avoid cheating.

Note: with the possibility of a leisurely purchase of traffic and a large number of suppliers, the game has an “ace in the hole” - the ability to assign a second point, which more accurately determines the efficiency of traffic. And also allows you to misbehave with suppliers, introducing bonus conditions for the type of "active player."

The simplest traffic flow diagram

Let's analyze the path of the visitor from the banner (or article) he saw to the game site.


In fig. 1 schematically shows the flow of users from a partner who has placed a banner on his resource, to the game site. As can be seen in the figure, we do not pour traffic directly to the site. Instead, we pass it through an intermediary - “PX_TDS”. Let us dwell on it in more detail.

Traffic Distribution System (PX_TDS)

TDS - Traffic (Directing | Distribution | Delivery) System is a class of software dedicated to traffic distribution. The main task of TDS is to distribute all incoming traffic among consumers in accordance with certain rules (for example, to send visitors with different language settings to different language versions of the site).

On the market there is a huge variety of TDS, sharpened for different directions. Such examples can be TDS for doorway, for mobile or any other traffic. But the most in demand TDS in the black business. For example, TDS is used to determine the set of vulnerabilities in browser settings and operating systems, sending a visitor to the right bunch of sploits.

Most often for commercial TDS there are many modules that improve the work with it in specific areas.

Note: if in the text you met abracadabra, starting with the prefix "PX_", remember - this is the name of our service. Usually, the name (part after the prefix) quite accurately conveys the essence of this service. We entered these prefixes so that you do not confuse the classes of systems and our software (as it could happen, for example, with PX_TDS and TDS).

PX_TDS is our own horizontal scaling traffic distribution system. When hit on PX_TDS, the user is assigned a globally unique visitor identifier (visitor_uid) and the “visitor.register” event is saved, after which it is redirected to the gaming site. The parameter visitor_uid is added to the address of the page to which the visitor is sent.

Despite its simplicity, this is a very important project. Due to its lightness and small load, it is remarkably scaled to small servers (up to virtual servers) and serves as a trouble-free entry point for the visitor.

The additional function PX_TDS is a selective redirection when some traffic is taken and sent to another URL. Thanks to this opportunity, we can test new Landing Page (“landing pages”) for conversion from existing traffic (the quality of which is already known).

If you apply a little imagination, then TDS can also become an emergency response system. For example, if the game site is not available, users are sent to the emergency blog or interactive user retention systems. The issue of traffic in moments of interruption is a very complex issue that captures marketing, game design, screenwriters, support. So, in itself is a separate topic for conversation.

Logical and physical traffic flow nodes

Returning to Figure 1, I would like to say that it was only a diagram. All nodes can be seen in Figure 2.

The physical node is the page through which the visitor passes.
A logical node is an entity that exists only to keep statistics and build reports.

Buyer - a person who buys traffic (logical node).
The target site is an Internet project that receives traffic from PX_TDS (logical node).
Advertising campaign - the page located on the website of the target where traffic is purchased (physical node).

Seller - a person selling traffic (logical node).
A donor site is an Internet project that sends traffic to a PX_TDS (physical or logical node).
The source is a subsidiary of the donor site (physical or logical node).

More I would like to dwell on the seller and its subsidiaries.

Imagine an online portal with a huge number of visitors. The standard advertising scheme for websites are banners and contextual ads. When the seller fills in the “questionnaire” of the donor site from which he would like to sell traffic, he indicates all available advertising spaces (these are the “sources”). The buyer sees them and decides whether to work with this advertising space or not.

The subtlety lies in the fact that the buyer can entrust the seller to add sources dynamically (and they will be paid for), and may not allow if he wants to receive traffic only from those sources that he checked himself. This option is called “Allow automatic creation of advertising spaces” (hereinafter referred to as “auto-creation”).

Even if the buyer trusts the seller, the latter is obliged to send traffic with a unique ID of the advertising space and his ID. This is necessary in order to track each source separately.

This thing is especially relevant when buying visitors on traffic exchanges (see Figure 3). By receiving statistics and estimating the incoming traffic of the supplier, we can abandon the specific sources of our partner, thereby achieving the maximum return.

This scheme suits us perfectly. But, due to the support of two levels, a paradox arises:

• Due to the large number of sources, the management of advertising spaces is possible only on large portals (on a large number of small sites this becomes tedious)
• Due to the lack of a third level of nesting, we do not support double referral systems (when the supplier of the exchange itself is an exchange)

Target site

Remember, PX_TDS sent to the visitor landing? In the address of the page, he kindly indicated to us visitor_uid, which the site carefully puts in the cookies.

When a player presses the play button (in fact, in our games, a hidden fact of creating a temporary user occurs here) or is registered through the form, our visitor_uid is taken from cookies and stored in the database.

By the way, if the visitor came to the target site not with PX_TDS, then the site itself generates visitor_uid and reports it to PX_TDS. In this case, if the source really cannot be calculated (REFERER does not contain information about popular portals like google, facebook and others), then the source of traffic is considered "Unknown".

There is another OMPW module, which has not been reviewed - PX_SERVER. Its main task is to import events into itself and provide WebAPI for data manipulation. But there is one more of its function - it consistently bypasses the sources of events (this issue will be discussed in the following parts) and saves them to its base (looking ahead, say, that the Python + Apache HBase bundle is used here).

A brief import algorithm is as follows:

• we take away from PX_TDS all new visitors with their data (visitor_uid, time, source, donor site, seller, buyer, target site, advertising campaign, etc.)
• we take away from the target site a list of all new users with their data (visitor_uid, user_id, time, etc.), combine them with the data from PX_TDS

Instead of conclusion

As a matter of fact, we considered only a small part of theory and practice, but now it is clear how to calculate the CTR for the Landing Page and the traffic efficiency at the “registration” point for different suppliers, how to connect a visitor on one server with a user on another server, which is already a lot.

Probably, the presented material will seem to someone too trivial. But we still hope that there is at least one habraiser who could use this post. One way or another, this is just the beginning, ahead of us are 4 more large parts of the Tale of Traffic. Subscribe to our blog if you do not want to miss the sequel.

Thanks for attention!
UPD: removed from the article what could have prevented thoughtful reading: “In each part of the traffic cycle, we will identify the 1st person who will receive a T-shirt from Oversun Media. As soon as we collect the size of 5 people, we will produce and send these small souvenirs. ”