Geekly Articles each Day
📜 ⬆️ ⬇️

Telegram Bots: Experience, Revelations, Design Tips

Let's get down to business right away. The content of the article:


Go.

What we started to do bots. Matchmaker, Weatherman, Zodiac.


Attention! The next paragraph may contain spoilers. Be careful.

All three bots turned out to be suitable and hang out now in the storebot.me top. Weatherman has consistently held in first place for several months.

Now a brief history of creation.
')
Developers do not feed bread - let me just nakodit some cool goofy garbage. Therefore, it was incredibly difficult for us to ignore the news about the launch of bots in Telegram.
First of all, it was necessary to come up with an idea for the first bot. Research started with Internet pillars - porn and cats.
It turned out that in Arab countries porn sites are blocked, and porn in the telegraph is available. This fact multiplied the attractiveness of pornbots for developers to infinity and the niche quickly filled.
And Serezha’s seals (Serezha is a developer in general, I’m writing current articles) are allergic.

Somewhere at the junction of porn and cats there was an idea to make a dating bot. Without thinking twice, we created Matchmaker_bot, an analogue of Tinder in Telegram (telegram.me/matchmaker_bot).
The idea of ​​a bot is simple and therefore beautiful - you upload a photo and then watch other people's photos. If you like a certain user, and you like him, the bot will allow you to exchange contacts and you can live happily and happily until death do you chat in the telegraph.

I can not share. At the first launch of the bot in the code was a bug that counted dislike for like. Because of this bug, I said a good ten brutal Iranians, who immediately joyfully began to chat with me.
Every time when I saw a notice in a telegram that a photo had come to me, I closed my eyes and ran to Seryozha to remove the photo — everything was waiting for obscenities. But polite Iranians have never sent anything indecent - only pictures with flowers and cats. Such are the romantic comrades.

For the first two days of life, the bot gathered 800 unique users, received 200 people daily audience and still the audience is growing.
At the time of this writing, we have 900 unique visitors per day.

We are not SEO website optimization specialists and, to be honest, we don’t imagine how to make a website that would attract a similar audience in two days without any special efforts.

Therefore, the result inspired us and Serezha quickly decided to make a couple more bots. Thus, Weatherman and Zodiac saw the light - bots that know how to give a weather forecast or horoscope, as well as send you daily forecasts for today or tomorrow at the time you specified (telegram.me/weatherman_bot and telegram.me/zodiac_bot).

Serezha got confused and made localization for bots in 5 languages, and for the weather bot he already took a paid weather API.
Multilingual, forecast accuracy and intuitive interface have suddenly made the weather bot very popular.
Now he is in the top of storebot.me, occasionally getting into the place of the coolest bot in Telegram, has more than 2000 user ratings, an average rating of 5 stars. Reviews are full of love and adoration.


Creating bot-brother nodejs for quick bot development


The first bot was written haphazardly, on bare enthusiasm. But the real developer understands - if you have to do about the same product many times, he starts to smack the framework. We did not find ready-made libraries or frameworks, so Seryozha wrote his lib.

Telegram Bot API allows using http-requests to receive or send text commands for dialogue with the user.
You can add special markup and variables to queries, for example, to show the user a simple keyboard.


In fact, the developer thinks in terms of several more complex abstractions.

1. You divide text messages from the user into two types - entering a command and responding to a bot request.

For example, there is a dialogue:
User: Bot, show me the weather forecast!
Bot: Ok, for which city?
User: Irkutsk
Bot: It's cold in Irkutsk ...

The first phrase of the dialogue is the initialization of the dialogue by the user, input of the command. And the third phrase is already the answer to the specific question of the bot.

2. All work with the bot is walking on some finite state machine.

Here you want to have the means for conveniently moving between states (commands), to be able to make child and parent states, to return to a new state, etc. etc. Simply put - I want to have a convenient tool for routing between teams.

3. You want to have a tool for convenient work with different languages.

I would like to have separate logic, separate configs for different languages. Ideally, language configs should be simple so that localization files can be outsourced for translation.

4. You want to organize sessions.

That is, to have some set of data that is tied to a unique bot user.

5. I want to break the processing of the team into several stages - middlewares.

Everyone loves the principles of express.js :)

All these ideas were embodied in the bot-brother library. We have tried to write detailed documentation for it, which can be found in the repository.

Boat per day. Using bot-brother on the example of a bot for notifications DeloreanBot.


If someone wants to skip the lyrics, you can touch the working bot in Telegram, and its sources look at the githaba.

For the rest, we describe the features of the implementation.
The functionality of the manufactured bot - the user enters into the bot reminders and time, the bot sends a notification at the right time.
For example, the user writes "Walk with the dog in an hour", the bot sends a reminder in an hour. (Let us immediately agree that we do not pretend to the originality of the idea). We make bot in Russian and English.

Writing such a bot completely and debugging and localizing the interface to English takes us one day.

We need:

1. Processing user commands

This is basically the basic bot-brother functionality. It makes no sense to duplicate the library documentation here. I will give a small piece of code for a common understanding. Registering a team and responding to its response usually looks like this:

//   settings_locale bot.command('settings_locale') .invoke(function (ctx) { //      –     return ctx.sendMessage(' '); }) .answer(function (ctx) { //      . ctx.session.locale = ctx.answer; ctx.setLocale(ctx.answer); return ctx.sendMessage('answer.success').then(function () { //    ,     . return ctx.goBack(); }); }) //      ,      . .keyboard([[ {'': 'ru'}, {'English': 'en'}, ], //   «»  . [{'': function (ctx) { ctx.goBack(); }] ]);


2. Organization of localization

If we ask a person to specify the interface language, it would be nice to show him texts in the correct language when working with a bot.

All phrases will be stored as “key-localized value” in yaml-files. This format is useful if you want to transfer files for editing to third-party translators. An example of a file with an English translation can be found here .

With the code we turn these files into json of the required format and transfer it to the bot.

The code for turning yaml-files into json is of no scientific interest, but if that is there .
 //      var bot = bb({ key: config.bot.key, redis: config.redis }) //       . .texts(texts.ru, {locale: 'ru'}) .texts(texts.en, {locale: 'en'}) .texts(texts.default);


After that, instead of text phrases, we will indicate the corresponding localization keys in the code.

All pieces of code with text message output will change slightly.
This code snippet
 .invoke(function (ctx) { //      –     return ctx.sendMessage(' '); })

transformed into
 .invoke(function (ctx) { //      –     return ctx.sendMessage('settings.locale'); })


3. Determining the user's time zone.

If you come up and ask an ordinary citizen to name your time zone, he may not understand you. But almost all human individuals are more or less sure of the name of the city in which they are located. We take advantage of this fact.

To determine the time zone, thus, you need to either directly request the user's location, or ask the user to type in the name of their city. Practice shows that this approach is good and does not scare anyone.

The name of the city is translated coordinates using Yandex http-geocoder (note, you need to get the key).

The coordinates feed timezoner , which will return us to the user's time zone.

There are nuances - both services have restrictions on the number of requests per day. Therefore:
a) we cache requests to the geocoder for identical cities;
b) when a person enters the exact location, we still run it through the geocoder, we get the city of the user and we work further with the coordinates of the city center - this way for all users from Moscow you can make one request in timezoner.

The code of the module for determining the time zone, see here .

4. User data storage

Previously, we noted that bot-brother can store data associated with a specific user for a long time. This functionality is implemented through Redis.

In more complex bots in Redis, we store only a small amount of user session data, and the bulk still have to be placed in a full-fledged database (for example, in MongoDB).

But for this bot decided to do only Redis.
Reading user data from the repository occurs before processing the next command, and writing back to the repository after the processing cycle of the next command.

5. Tracking the time at which you want to send a notification.

Our other bots need to send messages to users at certain times of the day. To do this, the server runs a process that checks the time, checks the records in the database and sends alerts regularly.

But for this bot there was a more cool solution. In Redis, you can add keys with a given lifetime. When the key goes out, Redis sends us the corresponding event. That's all.
As soon as we need to add a notification, we write down the key with the desired lifetime in Redis, and then we just listen to events and send notifications to users via them.
Code

6. Search for a time or date in a phrase

There is a wonderful library chrono-node , which can look for time in English phrases.
By analogy we add the code for the Russian language.

We now more or less represent:

Then it remains just to accurately program all the necessary commands for the bot and debug. We watch the full version in the same repository .

2 days. The flight is predictable.

We posted DeLorean on the storebot two days ago. Statistics:

Human recommendations for creating a popular bot


Above, we have shamelessly boasted that our bots have climbed to the top of the bots rating and have been sitting there for a long time.

Why is it important to have a high place in the ranking?

Of course, telegrams never publish magical algorithms, which are used to calculate the rating of bots. However, we have a hypothesis on this subject, which seems rather plausible.

So, your bot's rating is most dependent on recent storebot ratings. If your bot has recently been given a lot of positive ratings (5 stars), then it will most likely crawl up in the ratings.
The number of uniqueness in the bot and the intensity of its use do not seem to affect the position in the ranking. Otherwise, we cannot explain in any way how our Zodiac_bot manages to overtake in the ratings, for example, the super popular Yandex Yandex.Kartinok: /

Based on this thought, we conclude that the only way to promote a bot in the store is not to upset the bot's target audience and make users as happy as possible.

Now bots are a young and strange niche. The key feature of the overwhelming majority of bots is an incomprehensible interface.
The author of the article has formed a subjective feeling that bots are written by developers for developers. And for some reason, few people write bots for people.
If you make a bot for developers, then you can hardly raise it high in the ranking. Just because non-programmers will be confused in the interface and give low marks. Your cap.

In this regard, a few obvious recommendations on how to make a convenient bot for non-programmer users.

Keyboards instead of commands

Yes, I know that teams are very cool. Commands in the console, commands in the messenger - is this not happiness?
But, surprisingly, most of the world's population does not like to drive a team.
Hence, recommendation No. 1: so that absolutely any user does not fall into a stupor when working with your bot (even your grandmother), always, at almost any stage of working with the bot, show the user a keyboard with possible options for action. Leave the teams for the geeks, let them rejoice.

Do not ask people difficult things

I have already revealed this idea in principle in the section on determining the time zone. The less a user needs to think and click when working with your bot, the more chances that he will not fall off.

Feel free to use emoji

The feature of bots is a small amount of expressive means for creating attractive interfaces. Therefore, if we have the ability to make a button with an icon and text, it should be used.
I admit that many do not like the distortion of literary writing with vulgar pictures, but emoji really do make the text interface more friendly. An excellent illustration is the weather forecast.


Love negative reviews

Many negative reviews - not the worst situation for the product. The most terrible reaction - no one uses and writes nothing. Here it is really not clear what to do.
And when you have negative reviews, you can:
a) finish bot
b) fix bugs (if it's bug reports)
c) write to the author of a negative assessment and talk about the bot

We actively practice all three approaches. Serezha wrote many times to users who left some incomprehensible low-rated feedback, together they found a bug, repaired, and almost always the user returned to rate the bot more (which, as we know, contributes to its distribution).

Lyrical digression - the most funny reviews are left by the users of the dating bot.

But Mehregan is right, but what about the soul? ..

Philosophical reasoning about the monetization of bots


Theoretically, we understand that if we have an audience of 2,000 people a day, at least something can be earned from it. But almost do not understand how.
Now our headache is the growing needs of the weather bot. His audience is growing, requests for weather api are growing, and our costs of maintaining it, too. When growth stops - it is not clear.

We came up with three theoretical approaches to monetize a bot:
  1. Make a button for donations. Plus approach - unobtrusive. Cons - most likely the income will be close to zero.
  2. Paid subscription. We give to use the bot for free, for example, a month, then we ask to buy the key to the bot for the dollar. Pros - just do not leave a minus. Minus - we can lose all users.
  3. Advertising in the bot. Pros - the chances of earning it seems there. Cons - we can spoil the karma.

We are trying to develop approach number three, which is about advertising. Seryozha wrote a platform for advertising in adbot.io bots. You can read the dock and see the platform on the platform's website - adbot.io . It is completely new, as long as it contains only our bots and there are no advertisers at all. This is all a pure experiment for the time being, so we invite all those who are not indifferent to participate. We really want to find an arbitrazhnik who agrees to place advertisements in our bots (at first you can even be free), just to see if an advertising exchange is viable for bots.

If at least one of these approaches allows making bots profitable (or at least not unprofitable), then apparently the niche is not hopeless. And if it does not, apparently the botiki will die as a beautiful concept.

Source: https://habr.com/ru/post/270957/

More articles:


All Articles