Развивайте это развлечение, но после того, как вы закончите разработку, вы хотите увидеть, как пользователи используют ваш продукт, и измерить ваш успех, для этой цели мы собираем данные, которые представляют поведение пользователей, и сохраняем их для последующего анализа. Есть много способов сделать это, вы можете сделать это с помощью Mixpanel, Firebase, Google Analytics, вашей собственной службы или другими предпочтительными способами.

Я не собираюсь писать о том, как это сделать, я собираюсь описать решение, как согласовать данные в случае, если у вас есть несколько платформ, например сервер, мобильное приложение и веб-сайт, в этом случае каждая платформа ведет журнал по-разному. и часто с разными именами, это затрудняет отображение воронок и отслеживание кроссплатформенного поведения пользователей.
JavaScript сейчас очень распространен, так как вы можете выполнять всю разработку с помощью React и node.js, поэтому я представлю решение на JS.
Первый вопрос, который возникает, - как мы собираемся делиться кодом? Есть несколько способов сделать это:
- Скопируйте код везде (не очень хорошая практика)
- Загрузить в NPM (вам нужно будет создавать и обновлять для каждого внесенного изменения)
- Добавление в качестве подмодуля (если вы используете Git)
Добавление подмодуля
Из моей практики добавление подмодуля - лучшее решение, вы можете легко переключаться между ветвями и поддерживать его. Вы можете создать новый репозиторий (для обсуждения я назову его united-analytics) и привязать его к своему репозиторию, в котором вы хотите использовать аналитику.
Прежде чем мы начнем, вам нужно будет создать новый репозиторий, например, мы назовем его «объединенная аналитика», следующим шагом будет добавление его в ваш репозиторий, используя следующие шаги:
- Переходим в ваш репозиторий и запускаем эту команду git
git submodule add https://github.com/yourUser/united-analytics
2. Это добавит вашу аналитическую библиотеку в ваш репозиторий. Новая папка united-analytics, которая отслеживает, на какой сектор вы смотрите, и новый файл .gitmodules, который будет описывать ваш подключенный репозиторий. (Вам нужно будет зафиксировать пустую папку и .gitmodules в своем репо). Пример файла .gitmodules:
[submodule "united-analytics"] path = united-analytics url = https://github.com/yourUser/united-analytics
3. Для получения изменений вам нужно будет сделать это рекурсивно.
git pull --recurse-submodules
Единая аналитика
После того, как вы подключили united-analytics к своему репозиторию, давайте добавим код в united-analytics (в репозитории united-analytics). Я предлагаю использовать такую структуру:
src
- analytics
- events
- page
- eventType
- enentName
- interface
Теперь вы спрашиваете себя, зачем вам интерфейс? Ответ заключается в том, что мы решаем проблему согласования имен событий и действий, чтобы каждая платформа могла использовать собственное аналитическое решение с существующей инфраструктурой.
Интерфейс может выглядеть так:
interface IAnalyticsProvider {
logAnalytics(eventType: string, eventName: string, props: any)
}
И нам понадобится еще один класс, который все это контролирует, я назову его AnalyticsController:
import IAnalyticsProvider from "./Interface/IAnalyticsProvider";
let instance = null;
export default class AnalyticsController{
_analyticsProvider: IAnalyticsProvider = null
static get instance() {
if (!instance) {
instance = new AnalyticsController();
}
return instance;
}
init(analyticsProvider: IAnalyticsProvider){
this._analyticsProvider = analyticsProvider
}
get analyticsProvider(): IAnalyticsProvider{
return this._analyticsProvider;
}
static log(props){
if(!!props) {
if(!!AnalyticsController.instance.analyticsProvider) {
AnalyticsController.instance.analyticsProvider
.logAnalytics(
props.eventType,
props.event,
props.innerProps)
}else{
throw "analyticsProvider not initialized";
}
} else {
throw "missing mandatory props";
}
}
}
Таким образом, вы можете использовать свой собственный регистратор и просто реализовать для него интерфейс и запустить AnalyticsController с вашим собственным существующим классом аналитики.
... implements IAnalyticsProvider
init в начале вашего приложения
AnalyticsController.instance.init(HBAnalyticsController)
Теперь, когда у нас все настроено, мы можем начинать и строить события. Поскольку мы используем реквизиты, это объекты, которые представлены в структуре ключ / значение, поэтому мы можем построить наш отчет таким образом, например, отчет может выглядеть так:
{
pageName: "my_page",
eventType: "click",
event: "my_button_action"
...
}
Чтобы достичь этого, мы будем строить его агрегационным способом, это означает, что для каждого свойства мы создадим функцию, которая будет возвращать ключ и значение свойства, и если мы захотим добавить новое свойство, это будет так же просто. как добавление новой функции в соответствующий файл, который представляет связанный ключ.
Не смотрите в пример файла свойств pageName, так как, как я упоминал в структуре, этот файл будет расположен по адресу src \ analytics \ events \ page \ page.ts:
function processPage(props, name){
if(props === undefined){
props = {}
}
let innerProps = {}
innerProps.page = name
props.innerProps = {...props.innerProps, ...innerProps}
return props
}
export function myPage(props){
return processPage(props, "my_page")
}
и то же самое для других свойств соответственно, для свойства eventType это будет src \ analytics \ events \ eventType \ eventType.ts:
function processEvetType(props, name){
if(props === undefined){
props = {}
}
let innerProps = {}
innerProps.eventType = name
props.innerProps = {...props.innerProps, ...innerProps}
return props
}
export function click(props){
return processEvetType(props, "click")
}
Пример использования
После того, как мы закончили определять все события, которые хотим регистрировать, и добавили подмодуль в наш проект и запустили библиотеку, мы можем начать использовать построитель для регистрации событий, это будет просто:
AnalyticsController.log(myPage(click(myButtonAction())))
Таким образом, мы можем войти на все платформы и обернуть любую библиотеку ведения журнала, которая у нас уже есть, и иметь правильные и согласованные данные по всем воронкам.
Это предложение, как организовать и синхронизировать между разными репозиториями, и в идеальном мире они используют один и тот же язык, поэтому это просто, что, если они используют разные языки для разработки?
В этом случае вы можете использовать аналогичное решение, но вам нужно будет добавить еще один шаг, чтобы автоматизировать процесс сборки для создания выходных файлов для определенного языка, с которым вы интегрируетесь, например:
Надеюсь, вам понравилось, пожалуйста, оставьте комментарий, если у вас есть предложения или предложения по улучшению.