Добрый вечер, есть опыт использования tap-facebook, он в актуальном состоянии, но для того чтобы он нормально работал, нужно зарегистрировать приложение на фейсбуке и получить расширенный доступ для ads_read и Ads Management Standard Access.
Звучит как комментарий человека, знакомого с концепциями! :)
Мы сначала реализуем каждый атрибут независимо, но потом из независимых атрибутов собираем 1) широкую таблицу на анкер, просто left join‘ом всех атрибутов на анкер 2) широкую таблицу со всеми линками (по возможности).
То есть, когда появляется ещё один атрибут, мы добавляем ещё одну строчку left join’а в таблице анкера.
Это удобно для аналитики, для отображения в Metabase и sql-запросов.
Ща, погодите, у Singer же архитектура какая: - есть tap'ы – они для сбора данных из источников - есть target'ы – они для заливки данных в destination
Ну и соответственно если нужно данные из vk, например, залить в clickhouse, то надо взять tap-vk (например, наш), и target clickhouse. Target clickhouse кажется гуглится – https://www.npmjs.com/package/target-clickhouse например
https://arrows.app/ Вообще Arrows используется для визуализации labeled property graphs из домена графовых баз данных. Но выяснилось, что для визуализации моделей данных в терминах анкеров/атрибутов/линков тоже отлично подходит.
Привет! Мы тоже используем в работе производную от Anchor Modeling модель (Minimal Modeling). С событиями да, тоже замечали такую проблематику.
Сори, сейчас будет длинный комментарий :)
Вообще интересно, откуда берутся event'ы (давайте для простоты про мобильные event'ы только поговорим). Event’ы берутся из взаимодействия пользователя с интерфейсными элементами. Например:
USER clicked BUTTON
USER viewed PRODUCT_CARD итп
Где button, product_card - это реально анкера (в терминах Anchor Modeling), а действие с ними (USER clicked BUTTON) - это честный линк.
Но вместо «USER clicked BUTTON» логируется событие «green_button_click», которое содержит в себе след этого линка с потерей анкера + атрибуты.
В общем event - это реально линк, в котором мы потеряли информацию, и поэтому оно такое стрёмное.
Ещё про event’ы отдельно интересно, что они (почти) всегда достаточно хорошо документированы. Потому что прежде чем event’ы появляются в мобилке или на сайте, например, сначала появляется натурально ЭКСЕЛЬКА, в которой написано как именно какой event называется, когда логируется, какое-то у него есть описание, иногда даже скриншоты места в приложении откуда оно логируется.
Ну то есть у отдельного event’а самого по себе так-то довольно много самостоятельных описательных атрибутов.
Ну и простое следствие из этих рассуждений - что рядом с этим вот стрёмным анкером event есть анкер event_catalog со списком логируемых событий и их честными атрибутами.
И следующая мысль: а не получится ли на уровне вот этого event_catalog’а восстановить у event’а потерянный анкер и семантику линка (все равно event catalog это полностью ручная штука), и не появится ли от этого в event’ах интересного слоя дополнительного смысла.
Ну то есть, например, событие green_button_click не получится ли восстановить до USER clicked Button (с двумя анкерами, ликнком между ними и атрибутом green).
Мы как-то провели эксперимент и раскрыли User made Event в недостающие анкера и получилась вот такая штука:
То есть, в трекинг-плане например были события:
onboarding_shown
onboarding_second_step_shown
onboarding_third_step_shown
onboarding_fourth_step_shown
onboarding_fifth_step_shown
Каждое из этих событий – это атрибут линка "USER views ONBOARDING_SCREEN".
В общем мы сейчас размышляем о том, как бы на уровне инструмента ведения трекинг-планов вернуть потерянные анкера для этих event'ов. Потому что если получается так делать, то возникает еще интересная связка события с объектом реального мира (например, с конкретным товаром, item'ом итп)
Как переносить данные откуда угодно куда угодно с помощью Meltano
Добрый вечер, есть опыт использования tap-facebook, он в актуальном состоянии, но для того чтобы он нормально работал, нужно зарегистрировать приложение на фейсбуке и получить расширенный доступ для ads_read и Ads Management Standard Access.
Как настроить сквозную маркетинговую аналитику в режиме self-service (аналитики самообслуживания)
Звучит как комментарий человека, знакомого с концепциями! :)
Мы сначала реализуем каждый атрибут независимо, но потом из независимых атрибутов собираем 1) широкую таблицу на анкер, просто left join‘ом всех атрибутов на анкер 2) широкую таблицу со всеми линками (по возможности).
То есть, когда появляется ещё один атрибут, мы добавляем ещё одну строчку left join’а в таблице анкера.
Это удобно для аналитики, для отображения в Metabase и sql-запросов.
Как настроить сквозную маркетинговую аналитику в режиме self-service (аналитики самообслуживания)
Ща, погодите, у Singer же архитектура какая:
- есть tap'ы – они для сбора данных из источников
- есть target'ы – они для заливки данных в destination
Ну и соответственно если нужно данные из vk, например, залить в clickhouse, то надо взять tap-vk (например, наш), и target clickhouse. Target clickhouse кажется гуглится – https://www.npmjs.com/package/target-clickhouse например
Или вопрос в другом?
Аналитические дашборды не помогают принимать решения, или Где на самом деле брать инсайты из данных
Да ну ой, это тезис про качественные и количественные данные что ли?
Аналитические дашборды не помогают принимать решения, или Где на самом деле брать инсайты из данных
Ну как откуда данные! На дашборд посмотрели, там график "средний чек заказа по дням" – и вон, видно же, что упал! :)
Как настроить сквозную маркетинговую аналитику в режиме self-service (аналитики самообслуживания)
Привет! Легко:
- https://github.com/epoch8/tap-yandexdirect
- https://github.com/epoch8/tap-vk
Если будут вопросы – пишите olga@epoch8.co
Как настроить сквозную маркетинговую аналитику в режиме self-service (аналитики самообслуживания)
А, или речь идет о картинке с Lineage? Такие штуки рисует https://getdbt.com/
Как настроить сквозную маркетинговую аналитику в режиме self-service (аналитики самообслуживания)
https://arrows.app/ Вообще Arrows используется для визуализации labeled property graphs из домена графовых баз данных. Но выяснилось, что для визуализации моделей данных в терминах анкеров/атрибутов/линков тоже отлично подходит.
Дилемма моделирования в рамках Data Vault/Anchor Modeling: объект или событие
Привет! Мы тоже используем в работе производную от Anchor Modeling модель (Minimal Modeling). С событиями да, тоже замечали такую проблематику.
Сори, сейчас будет длинный комментарий :)
Вообще интересно, откуда берутся event'ы (давайте для простоты про мобильные event'ы только поговорим). Event’ы берутся из взаимодействия пользователя с интерфейсными элементами. Например:
USER clicked BUTTON
USER viewed PRODUCT_CARD итп
Где button, product_card - это реально анкера (в терминах Anchor Modeling), а действие с ними (USER clicked BUTTON) - это честный линк.
Но вместо «USER clicked BUTTON» логируется событие «green_button_click», которое содержит в себе след этого линка с потерей анкера + атрибуты.
В общем event - это реально линк, в котором мы потеряли информацию, и поэтому оно такое стрёмное.
Ещё про event’ы отдельно интересно, что они (почти) всегда достаточно хорошо документированы. Потому что прежде чем event’ы появляются в мобилке или на сайте, например, сначала появляется натурально ЭКСЕЛЬКА, в которой написано как именно какой event называется, когда логируется, какое-то у него есть описание, иногда даже скриншоты места в приложении откуда оно логируется.
Ну то есть у отдельного event’а самого по себе так-то довольно много самостоятельных описательных атрибутов.
Ну и простое следствие из этих рассуждений - что рядом с этим вот стрёмным анкером event есть анкер event_catalog со списком логируемых событий и их честными атрибутами.
И следующая мысль: а не получится ли на уровне вот этого event_catalog’а восстановить у event’а потерянный анкер и семантику линка (все равно event catalog это полностью ручная штука), и не появится ли от этого в event’ах интересного слоя дополнительного смысла.
Ну то есть, например, событие green_button_click не получится ли восстановить до USER clicked Button (с двумя анкерами, ликнком между ними и атрибутом green).
Мы как-то провели эксперимент и раскрыли User made Event в недостающие анкера и получилась вот такая штука:
То есть, в трекинг-плане например были события:
onboarding_shown
onboarding_second_step_shown
onboarding_third_step_shown
onboarding_fourth_step_shown
onboarding_fifth_step_shown
Каждое из этих событий – это атрибут линка "USER views ONBOARDING_SCREEN".
В общем мы сейчас размышляем о том, как бы на уровне инструмента ведения трекинг-планов вернуть потерянные анкера для этих event'ов. Потому что если получается так делать, то возникает еще интересная связка события с объектом реального мира (например, с конкретным товаром, item'ом итп)