Help: Begin recording a few stats pertaining to the help section.

[dllh]

At present we're recording no stats for actions taken in the help section. This PR begins recording the basic things we'd like to record. Specifically it records events for views of /help and /help/contact, chat initiation, contact form submits, display of contact form views when chat is unavailable, and search queries. I think we should also look into adding some event properties congruent with what we're logging elsewhere, but this gives us a baseline to build on.

To test:

• Load /help
• Do a search
• Load /help/contact
• Start a chat or submit a contact form

Check the tracks live view for your user in our internal tool after a few minutes to see if your stats come through.

I note that we seem to fire some of these multiple times. For example, when I load the contact form view because no chat operators are available, I see that the stat fires a couple of times at least in some cases. I'm not sure why this is happening and would be grateful for any insight. Update: I've fixed this (and leave this statement in the description because it comes up in the comments below and it'd be weird to delete it and lose context).

A note on naming. Arguably, it's a little weird that the chat stat is named calypso_help_live_chat_begin while the non-chat contact form stats are named calypso_help_contact_submit. A case could be made for using the latter name in all cases and merely passing chat as the type in the event property. My choice to separate the naming is based on the fact that we have similarly named stats for chat initiation in other code, and we do not at present have an event for submit of other contact forms. So I'm standardizing the chat naming scheme to match prior naming conventions while introducing a new name for non-chat ticket creation. I'm surely open to feedback re naming but wanted to explain the rationale behind the original decision.

This commit also incidentally fixes up some ellipses that didn't pass linter tests.

This PR addresses issue #1348.

[dllh]

Ping @scruffian since a quick search of recent PRs touching analytics stuff turns up a fair bit of activity on your part. Mind giving this a look?

[omarjackman]

I'm not sure but I think we might end up with a bunch of these events because of multiple re-renders that aren't related to the form switching. I'd consider moving this to the onOperatorsAway method and wrapping it with the proper conditionals.

[dllh]

@omarjackman thanks for that suggestion. I've updated, and it works better as implemented now. One thing I'm not sure about is defining all the consts here. It feels a bit like I'm repeating code from elsewhere, but I don't know if there's a better way. Do you think it's reasonable or is there a better approach I might try?

[timmyc]

I set my debug to calypso:analytics and could see that all the events were firing properly. I did search for calypso_help_live_chat_begin in the internal tool and did not see any recent tracks - but I think this is due to running in dev mode and those being ignored.

But typically for analytics testing seeing the events logged in the console will suffice.

I did encounter two oddities while doing the tests:

1- Having a really long site name breaks the form a bit:

2- When the operator said they were going to end the chat, I did not see anything else displayed ( I thought there is a message that is shown when the operator does a !end ), and did see the following message in my console:

I'm guessing neither of these are really related to this PR but figured they were note worthy still :)

For the tracking bits, this LGTM 👍

[dllh]

Thanks for looking! The long site name will likely be addressed when #1588 lands. The other issue is sort of by design but probably needs to be re-evaluated, and we're looking into maybe improving the notices around similar scenarios in #1340 and #1341.

In my testing, I did see stats in our live console view, but they were often quite delayed (and I think there's currently a known issue with delay of some stats), so I think we're ok there. Really appreciate the speedy review.