Track chatbots using Adobe Analytics

22 May 2016 » Analytics Tips

According to some news, all major Internet players are now focusing on chatbots. I have never used one but it looks like with the progress in artificial intelligence, we will all be using them in the not-so-distant future. Facebook even claims that thousands of developers are creating right now chatbots. If this is true, then we should be ready for them.

While I read this news, I thought, how about using Adobe Analytics to track the conversations? Would it make sense to large corporations, which already have Adobe Analytics, to use the same tool as with website and apps? I know some people will contend that my idea is wrong, that chatbots will need a different reporting tool. However, I would then reply that, a few years ago, it was not clear whether Adobe Analytics would be used for apps; now, all my clients, want to integrate Adobe’s SDK in all their apps.

As you may imagine, I have not yet been involved in a chatbot project, but if I had to do it, these are some ideas that I would put into practice.

  • Report suite. All chatbot data should be in a report suite, which does not receive any web or app data. In case of having various bots, each could have its own report suite or all could share the same report suite and an eVar + a prop could be used to identify the bot.
  • Data insertion API. I very much doubt that you will be able to add JavaScript code to your replies. So, tracking will have to be done server-side.
  • Visitor identification. I presume that you will get a means to uniquely identify the user or, in the worst case scenario, the conversation. I would generate a random unique ID based on this information.
  • Page views. Every message from both sides should count as a page view.
  • Visits. If you have no means to detect that a conversation is finished, then just allow for the standard visit definition. On the other hand, if you can detect the end of a conversation, I would try to force the expiration of the previous visit with a specific event and VISTA rule.
  • Page name. This is probably the most complicated part to generate. I am not an expert in AI, but I would presume that it is possible to extract the meaning of the message. Therefore, it should be possible go generate a finite number of message names. However, if I were to create the implementation, I would discuss it in greater detail with the developers.
  • Props. I do not see much use for props, at least in general. One idea would be to classify the messages in broad types; another one to track the steps a user has to take to reach a desired goal.
  • Events and eVars. Every time the user requests something that is meaningful for the chatbot, I would generate an event. If this event had some additional information, it would go into eVars. For example, in the case of a weather chatbot, every time there is an explicit request for a weather forecast (what will the weather be in London tomorrow?), you could track:
    • Weather request: event
    • Location: eVar
    • Timespan: eVar
    • Days from today: eVar
    • Celsius or Fahrenheit: eVar
  • Products. If the chatbot can sell products, then this variable should be used, together with the typical events (prodView, scAdd, scRemove, scView, scCheckout, purchase). Remember to use purchaseID and transactionID if needed.
  • Campaign. If it is possible to detect how the user found the chatbot (an ad, a link from a website, a bots directory…), the s.campaign variable should be used to track this information at the beginning of the session.
  • Location. Ideally, if you could get the IP address of the user, you could send it to Analytics and use the out-of-the-box reports. Otherwise, any location information could be stored in an eVar (or eVar + prop).

In general, I must admit there are many unknowns as of yet. As time progresses and with more experience, this initial approach will change. However, if I had to work on such a project now, this list would be my starting point.

Related Posts