
In the first article, we “broke the covers” and told
us what call tracking is . Then we detailed
its settings , now about how we created this service at Mango Telecom and what technology stack we use.
This story began about 2 years ago. We wanted to find new business lines in addition to the main one - telephony. We discussed the options for a long time and as a result made a list of about 10 potentially interesting products and services. The idea of call tracking seemed to be the most promising, given our capabilities: we are a telephone operator, we have our own virtual PBX and we own a large pool of telephone numbers.
So, we decided to implement call tracking.
')
Start
Began to think how to do it. It was clear that the entire “telephone” part of the project should be built on the basis of our VATS. There is one legal aspect: according to the law, numbers cannot be sold to customers, in fact, we rent rooms. In addition, you can redirect the call to the client by the rented number only under the condition of the concluded agreement on the services of VATS. Therefore, we considered billing for a long time - how to correctly calculate expenses, which model to choose. In the end, they created a special technical VATS, to which they assigned the entire pool of numbers, and built a billing on its basis.
Allocation of numbers
All the developers of call tracking systems face one difficulty: the client connected the number, the number was displayed for some user, and he picked it up and wrote it down on a piece of paper. People write down any useful information not to forget. After some time, the number “got rid” of a specific client, and then the user decided to call, and the number was already from a completely different company.
We started to invent our number rotation mechanism, which would use the numbers more carefully, but did not violate the main principle: to provide the client with the necessary number of numbers to call for real traffic on the site and thus ensure maximum accuracy.
Now the numbers stand out like this:
- The client connects call tracking and places a widget on the site.
- As soon as a visitor appears on the client's site, the IP system determines its region. This is done on a table that we store in PostgreSQL.
- Call Tracking checks if there are free rooms in the region to show the site visitor a phone with the code of the desired city. The number capacity for each region is constantly monitored and, if necessary, replenished.
- OK, the number is - go ahead. The system identifies the visitor’s marketing metrics and matches them with the number he calls.
Everything described above refers to the situation when the client has “Multi-regional” connected, that is, they can call him from several cities where he places advertisements.
If the client’s business is concentrated in one region and its advertising is only for local residents, there is no sense in multiregional. The client simply sets his region as a home one in the settings for call tracking, and the system will show local numbers to all site visitors, even if by IP we understand that visitors are not local.
Two weeks from the date of the last call or display on the site, the number is still assigned to the company. This is a guarantee that the visitor of her site will get through to the right place. Further, if there were no calls, the number goes to a special storage, where it remains from three months to six months - it depends on the load on the service.
Such a scheme made it possible to make the dynamic size of a pool of numbers bound to a widget. The client does not need to worry about whether there will be enough numbers, if the advertising campaign suddenly comes more users than predicted. The numbers will be added automatically in addition to those already assigned to the client, so there will be no degradation in the quality of call tracking.
Call handling
So, the user calls the number shown to him on the site. The call comes to our technical vats. The switch sends one request with a number to the database (DB) and receives the answer: which client company needs to redirect the call to the SIP line. The switch redirects the call, and its further “landing” depends on the client settings of the redirection to the VATS. You can redirect the call to a certain division of the company, start a regular greeting or a voice menu of any complexity, set up a waiting scheme and much more. There are no such possibilities in most other call tracking systems on the market.
When something arrives at the technical PBX and the switch, events are tracked to the call tracking service, where it is monitored, where the call came from, when it ended and with what status. All this information is stored in a separate MongoDB. Because in the main database for all calls over many years, billions of records have accumulated, and it is unreasonable to store in it also the call tracking data. It is on the basis of data from a separate database that a report is generated on calls with extended detail. In this report, the client sees the UTM label of the channel through which the user came. That is, you can determine the specific source and advertising campaign that led the call. Sometimes keywords are added from a search query. It happens that the advertisement that interested the user fits entirely into the UTM tag. All this allows you to build aggregated reports by channels, sources and advertising campaigns. The calls themselves are recorded, and if desired, customers can listen to them.
The system automatically divides calls by novelty and quality. New ones are calls from numbers from which they have not called the company yet. And the quality criterion is simple: the duration of the conversation without taking into account the time spent by the user on dialing and listening to the voice menu. If the client installs a "Call Center" (our tool for contact centers), he will be able to assign categories (tags) to calls for more precise analysis.
End-to-end analytics
Let's go back to our additional database. It also stores user sessions on customer sites. When a call ends, its statistics are matched with session information. But customers of this data, as a rule, is not enough. They want to know how much money was spent on a particular channel in order to evaluate its effectiveness and calculate the cost of attracting circulation. This is solved with the help of integration:
- with advertising platforms Yandex.Direct and Google AdWords (in the future we plan to add integration with advertising systems of social networks);
- with CRM clients (for uploading transaction information).
All this allows you to calculate through advertising channels and campaigns the number of clicks to the site, the number of calls and other types of calls, how much was spent, how many transactions were made and how much income was received. As a result, it is possible not only to calculate the specific efficiency of each ruble invested in an advertisement, but also to identify shortcomings in advertising or flaws in the sales department.
Additionally, in analytical reports we take into account applications from the forms on the sites, as well as callbacks, so that the statistics take into account those users who did not want to spend money on the call and clicked the "Call me back" button. As you know, callbacks increase the conversion, so that their accounting improves the accuracy of analytics.
Since the creation of analytical reports uses information from external sources, to generate such reports in real time will not work with all the desire. Third-party services have their own frequency of updating the data that we need to download and process. Therefore, we build reports once a day. This is a complex, step-by-step procedure: data from different sources are first downloaded and then aggregated: interconnections are sequentially established and a large table is obtained, on the basis of which the final report is built in the user interface. By the way, clients usually need such reports retrospectively: they run an advertisement, wait a week and look at the results, what happened there.
Technology stack
When creating and developing products, one always has to take into account the requirements of the market and the wishes of customers. The main thing is to set priorities correctly. We analyze how much resources and time it will take to create a particular feature, and how much it affects the client’s business, draw up a development plan and start creating. Minor updates are issued every two weeks. Once a couple of months, we implement large functions. Last week we released an update with easy installation of call tracking. The widget no longer needs to be added to a strictly defined code fragment (instead of the phone), it works, even if you put it at the end of the page. Or in the beginning. Anywhere. For inexperienced users, this should simplify the launch of the service.
All our solutions are based on microservice architecture. To implement complex business case call handling, we created several APIs. And the main role is assigned to the so-called WATS API. This is a software interface with which you can widely customize the processing of a call. It is possible to calculate where to redirect it, and not only on the basis of data available in the call tracking system. For example, if you need to show a
specific number in a particular ad . For example, in a card of some product in an online store, you can show a unique number that is calculated dynamically, and transfer a call to this number to a specific employee by receiving the incoming web call hook and calculating according to the internal business processes of the company where to forward it .
You can also use our own REST API for call tracking. It allows you to upload information about calls, and also supports web hooks. At the beginning and end of each call, we call a client web hook. This is often used for integration with CRM and analytical systems.
To configure the widget code on the client’s website, we use fairly sophisticated JavaScript API. It allows you to set different events for downloading the number, format the appearance of the number literally to the HTML level and do much more.
The high-loaded part related to call processing is based on Node.JS. Simpler components are written in PHP. The user interface is based on the Angular JavaScript framework. In telephony, mainly C ++. For the internal integration of all services, the RabbitMQ queue server is used. It acts as a bus for exchanging data between call tracking and other company products.
All WATS and calltracking user settings are stored in PostgreSQL. This is a reliable relational database that ensures data integrity. Site traffic statistics, statistics of numbers and calls made are written in MongoDB. We chose this database because it is easier to maintain compared to SQL solutions. And for online data storage, access to which is required in real time, we use Redis. It contains information about current call tracking numbers and their binding to clients.
Due to the fact that we have developed the entire chain of products providing voice communication, call accounting and other types of calls, as well as due to the close integration of all our services among themselves, storing the VATTS settings and the switch in a single database, and the data on the numbers used - in RAM , a synergistic effect occurs: calls are processed very quickly. For rapid assessment of the effectiveness of advertising, you can watch the data online. And for a full analysis, you need to wait a bit for the system to load updated data from third-party services and CRM within 24 hours. And since we ourselves use our own products, they get into commercial operation only after testing in our daily work and eliminating all found rough edges.