Botonic Plugin Google Analytics

[asastre]

Description

New plugin to track user interaction or bot's behaviour to Google Analytics.

Context

Tracking information to Google Analytics is very usual nowadays and for some companies there is the need to track the user interaction with the bot to Google Analytics.

Approach taken / Explain the design

This plugin provides a basic tracking with its method track and it has to be done manually, there is no default tracking through the pre or post methods.

To documentate / Usage example

See Readme.md file for documentation/examples.

Testing

The pull request...

• has unit tests
• has integration tests
• doesn't need tests because... no tests needed

[dpinol]

🚀 a new plugin for botonic!

[vanbasten17]

Cool!! Publish it freely once you have considered the feedback! 🚀

[asastre]

@dpinol @vanbasten17 after doing some tests with the Google Analytics tracking I did a refactor of the track method to match correctly the fields of eventFields with the GA fields.

I've removed the async/await of track method because, as I said in a comment before, it doesn't make sense to stop the execution of the bot while doing the tracking.

I've also added more and better documentation of the track method.

[ericmarcos]

@dpinol @vanbasten17 after doing some tests with the Google Analytics tracking I did a refactor of the track method to match correctly the fields of eventFields with the GA fields.

I've removed the async/await of track method because, as I said in a comment before, it doesn't make sense to stop the execution of the bot while doing the tracking.

I've also added more and better documentation of the track method.

@asastre please leave the async and state in the docs that you must await this call. As we're running this in Lambda, the main "thread" can finish and the process terminated leaving async calls that are not awaited terminated before they end the execution.

[asastre]

@dpinol @vanbasten17 @ericmarcos changes done. I restored the async/await in track method, as you said, in production the plugin will be executed in lambda and it needs to be sure it will execute.

[dpinol]

@asastre review the prettier errors in CI checks. More important, your pre-commit should not have let you comit this file. Please verify that you did "pre-commit install" on your botonic checkout
/home/runner/work/botonic/botonic/packages/botonic-plugin-google-analytics/src/index.js
##[error] 62:35 error Replace this.userId({·session·}),·this.userTraits({·session·}) with ⏎······this.userId({·session·}),⏎······this.userTraits({·session·})⏎···· prettier/prettier

[asastre]

@dpinol @ericmarcos I've made some changes/enhancements:

• Refactor name methods defaultUserId and defaultUserTraits to getUserId and getUserTraits.
• Refactor the option trackManually to automaticTracking to clarify its usage. If this option is not set, its default value will be true, enabling the automatic tracking on each user interaction.
• Added a new option: eventFields to enable to send custom event fields to the automatic tracking done by the plugin (only used if automaticTracking is not set or is set to true)

[dpinol]

lgtm 🚀

[dpinol]

can you comment on why you removed the default getUserId?

[asastre]

can you comment on why you removed the default getUserId?

I removed it because at first we were assuming that clientId and userId were the same for Google Analytics, but they are different concepts and userId is meant to represent a logged user, so the plugin can't add one by default, the user must provide one if they want to track it.

[asastre]

@dpinol @ericmarcos The plugin wasn't working properly when tracking on the server side loosing events randomly and never reaching Google Analytics.
After trying various tracking packages (@analytics/google-analytics, universal-ga) and even proposing changes to one of them so the clientId parameter could be sent in the server side tracking (feature needed to keep the tracking flow for both client and server side), the tracking on the server side didn't work as expected, probably because it's executed in Lambda.
The new aproach (which is working fine) is to make direct requests to Google Analytics (using axios) sending the parameters needed each time.