Учурда дүйнөдөгү дээрлик ар бир компания веб-ресурста колдонуучунун аракеттери тууралуу статистиканы чогултат. Мотивация түшүнүктүү - компаниялар алардын продуктусу/веб-сайты кандайча колдонуларын билгиси келет жана колдонуучуларын жакшыраак түшүнгүсү келет. Албетте, рынокто бул көйгөйдү чечүү үчүн көптөгөн куралдар бар - маалымат такталары жана графиктер түрүндө берген аналитикалык системалардан баштап (мисалы ) ар кандай кампадагы ар кандай булактардан маалыматтарды чогултууга жана бириктирүүгө мүмкүндүк берүүчү Кардар маалыматтарынын платформасына (мисалы ).
Бирок биз али чечиле элек маселени таптык. Ошентип төрөлгөн — ачык булактуу аналитика кызматы. Эмне үчүн биз өзүбүздүн кызматыбызды иштеп чыгууну чечтик, ал бизге эмне берди жана натыйжасы кандай болду (коддун даанасы менен).
Эмне үчүн биз өзүбүздүн кызматыбызды өнүктүрүшүбүз керек?
Токсонунчу жылдар болчу, колдон келишинче аман калдык. 2019, биз API Биринчи Кардар маалыматтарынын платформасын иштеп чыктык kSense, бул ар кандай булактардан алынган маалыматтарды (Facebook жарнактары, Stripe, Salesforce, Google play, Google Analytics ж.б.) бириктирүүгө мүмкүндүк берген, маалыматтарды ыңгайлуураак талдоо, көз карандылыкты аныктоо ж.б. Көптөгөн колдонуучулар биздин платформаны, атап айтканда, Google Analytics (мындан ары GA) маалыматтарды талдоо үчүн колдонорун байкадык. Биз кээ бир колдонуучулар менен сүйлөшүп, алар GA аркылуу алган өнүмүнүн аналитикалык маалыматтарына муктаж экенин билдик, бирок жана көптөр үчүн GA Колдонуучу интерфейси ыңгайлуулуктун стандарты эмес. Биз колдонуучуларыбыз менен жетиштүү маектештик жана көпчүлүгү Segment платформасын да колдонуп жатышканын түшүндүк (баса, бул өткөн күнү эле ).
Алар веб-ресурстарына Сегменттин JavaScript пикселин орнотушту жана алардын колдонуучуларынын жүрүм-туруму жөнүндө маалыматтар көрсөтүлгөн маалымат базасына жүктөлдү (мисалы, Postgres). Бирок Сегменттин да терс жагы бар - баасы. Мисалы, веб-ресурста 90,000 1,000 MTU (ай сайын көзөмөлдөнүүчү колдонуучулар) болсо, анда кассирге айына ~ XNUMX доллар төлөшүңүз керек. Үчүнчү маселе дагы бар эле - кээ бир браузер кеңейтүүлөр (мисалы, AdBlock) аналитика жыйнагын бөгөттөп койгон, анткени... Браузерден http сурамдары GA жана Segment домендерине жөнөтүлдү. Кардарларыбыздын каалоолорунун негизинде биз маалыматтардын толук топтомун чогултуучу аналитика кызматын түздүк (үлгүсүз), бекер жана биздин жеке инфраструктурабызда иштей алат.
Кызмат кантип иштейт
Кызмат үч бөлүктөн турат: JavaScript пиксели (биз аны кийинчерээк типографияда кайра жаздык), сервер бөлүгү GO тилинде ишке ашырылган жана Redshift жана BigQuery'ди ички маалымат базасы катары колдонуу пландаштырылган (кийин биз колдоону коштук. Postgres, ClickHouse жана Snowflake).
ГА жана Сегмент окуяларынын түзүмүн өзгөртүүсүз калтыруу чечими кабыл алынды. Болгону, пиксел орнотулган веб-ресурстагы бардык окуяларды биздин серверге көчүрүү керек болчу. Көрсө, муну жасоо кыйын эмес. Javascript пиксели GA китепканасынын баштапкы ыкмасын жаңысы менен жокко чыгарды, ал окуяны биздин системага кайталады.
//'ga' - стандартное название переменной Google Analytics
if (window.ga) {
ga(tracker => {
var originalSendHitTask = tracker.get('sendHitTask');
tracker.set('sendHitTask', (model) => {
var payLoad = model.get('hitPayload');
//отправка оригинального события в GA
originalSendHitTask(model);
let jsonPayload = this.parseQuery(payLoad);
//отправка события в наш сервис
this.send3p('ga', jsonPayload);
});
});
}
Сегменттин пиксели менен бардыгы жөнөкөйлөштүрүлөт, анын ортолук ыкмалары бар, алардын бирин биз колдонгон.
//'analytics' - стандартное название переменной Segment
if (window.analytics) {
if (window.analytics.addSourceMiddleware) {
window.analytics.addSourceMiddleware(chain => {
try {
//дублирование события в наш сервис
this.send3p('ajs', chain.payload);
} catch (e) {
LOG.warn('Failed to send an event', e)
}
//отправка оригинального события в Segment
chain.next(chain.payload);
});
} else {
LOG.warn("Invalid interceptor state. Analytics js initialized, but not completely");
}
} else {
LOG.warn('Analytics.js listener is not set.');
}
Окуяларды көчүрүүдөн тышкары, биз ыктыярдуу json жөнөтүү мүмкүнчүлүгүн коштук:
//Отправка событий с произвольным json объектом
eventN.track('product_page_view', {
product_id: '1e48fb70-ef12-4ea9-ab10-fd0b910c49ce',
product_price: 399.99,
price_currency: 'USD'
product_release_start: '2020-09-25T12:38:27.763000Z'
});
Андан кийин, сервер бөлүгү жөнүндө сүйлөшөлү. Backend http суроо-талаптарын кабыл алышы керек, аларды кошумча маалымат менен толтурушу керек, мисалы, гео маалыматтар (рахмат бул үчүн) жана аны маалымат базасына жазыңыз. Биз кызматты минималдуу конфигурация менен колдонууга мүмкүн болушунча ыңгайлуу кылгыбыз келди. Биз келген json окуясынын структурасынын негизинде маалымат схемасын аныктоо функциясын ишке ашырдык. Маалымат түрлөрү баалуулуктар менен аныкталат. Уяланган объекттер ыдырап, жалпак түзүлүшкө чейин төмөндөйт:
//входящий json
{
"field_1": {
"sub_field_1": "text1",
"sub_field_2": 100
},
"field_2": "text2",
"field_3": {
"sub_field_1": {
"sub_sub_field_1": "2020-09-25T12:38:27.763000Z"
}
}
}
//результат
{
"field_1_sub_field_1": "text1",
"field_1_sub_field_2": 100,
"field_2": "text2",
"field_3_sub_field_1_sub_sub_field_1": "2020-09-25T12:38:27.763000Z"
}Бирок, учурда массивдер саптарга айландырылат, анткени Бардык реляциялык маалымат базалары кайталануучу талааларды колдой бербейт. Талаалардын аталыштарын өзгөртүү же кошумча карта түзүү эрежелерин колдонуу менен жок кылуу да мүмкүн. Алар зарыл болсо, маалымат схемасын өзгөртүүгө же бир маалымат түрүн башкасына алмаштырууга мүмкүндүк берет. Мисалы, json талаасы убакыт белгиси бар сапты камтыса (талаа_3_кошумча_талаа_1_суб_талаа_1 Жогорудагы мисалдан), андан кийин маалымат базасында убакыт белгиси түрү менен талаа түзүү үчүн, конфигурацияда карта түзүү эрежесин жазышыңыз керек. Башкача айтканда, талаанын маалымат түрү адегенде json мааниси менен аныкталат, андан кийин типти кастинг эрежеси (конфигурацияланган болсо) колдонулат. Биз 4 негизги маалымат түрлөрүн аныктадык: STRING, FLOAT64, INT64 жана TIMESTAMP. Карта түзүү жана типке чыгаруу эрежелери төмөнкүдөй көрүнөт:
rules:
- "/field_1/subfield_1 -> " #правило удаления поля
- "/field_2/subfield_1 -> /field_10/subfield_1" #правило переноса поля
- "/field_3/subfield_1/subsubfield_1 -> (timestamp) /field_20" #правило переноса поля и приведения типа
Маалыматтын түрүн аныктоо алгоритми:
- json түзүмүн жалпак түзүлүшкө айландыруу
- маанилер боюнча талаалардын маалымат түрүн аныктоо
- карта түзүү жана түрүн чыгаруу эрежелерин колдонуу
Андан кийин келген json структурасынан:
{
"product_id": "1e48fb70-ef12-4ea9-ab10-fd0b910c49ce",
"product_price": 399.99,
"price_currency": "USD",
"product_type": "supplies",
"product_release_start": "2020-09-25T12:38:27.763000Z",
"images": {
"main": "picture1",
"sub": "picture2"
}
}
маалымат схемасы алынат:
"product_id" character varying,
"product_price" numeric (38,18),
"price_currency" character varying,
"product_type" character varying,
"product_release_start" timestamp,
"images_main" character varying,
"images_sub" character varying
Биз ошондой эле колдонуучу бөлүштүрүүнү конфигурациялоо же маалымат базасындагы маалыматтарды башка критерийлерге ылайык бөлүштүрүү мүмкүнчүлүгүнө ээ болушу керек деп ойлодук жана таблица атын туруктуу же белги менен коюу мүмкүнчүлүгүн ишке ашырдык конфигурацияда. Төмөндөгү мисалда окуя продукт_type жана _timestamp талааларынын маанилеринин негизинде эсептелген аты менен таблицага сакталат (мисалы supplies_2020_10):
tableName: '{{.product_type}}_{{._timestamp.Format "2006_01"}}'
Бирок, келген окуялардын структурасы иштөө убагында өзгөрүшү мүмкүн. Учурдагы таблица менен келген окуянын структурасынын ортосундагы айырманы текшерүү үчүн алгоритмди ишке ашырдык. Эгерде айырма табылса, таблица жаңы талаалар менен толукталат. Бул үчүн, патч SQL сурамын колдонуңуз:
#Пример для Postgres
ALTER TABLE "schema"."table" ADD COLUMN new_column character varyingархитектура
Эмне үчүн окуяларды жөн гана маалымат базасына жазбастан, файл тутумуна жазуу керек? Маалыматтар базалары көп сандагы кыстармалар менен иштөөдө дайыма эле жакшы иштей бербейт (). Бул үчүн, Logger келген окуяларды файлга жазат жана өзүнчө горутинге (жипке) Файл окугуч файлды окуйт, андан кийин маалыматтар конвертацияланат жана аныкталат. Таблица менеджери таблица схемасынын актуалдуу экендигине ынангандан кийин, маалыматтар бир партияда маалымат базасына жазылат. Кийинчерээк биз маалымат базасына түз жазуу мүмкүнчүлүгүн коштук, бирок биз бул режимди көп эмес окуялар үчүн колдонобуз - мисалы, конверсиялар.
Open Source жана келечекке пландар
Кайсы бир убакта, кызмат толук кандуу продукт сыяктуу көрүнө баштады жана биз аны Open Sourceге чыгарууну чечтик. Учурда Postgres, ClickHouse, BigQuery, Redshift, S3, Snowflake менен интеграциялар ишке ашырылган. Бардык интеграциялар маалыматтарды жүктөөнүн пакеттик жана агымдык режимдерин колдойт. API аркылуу сурамдарды колдоо кошулду.
Учурдагы интеграция схемасы төмөнкүдөй көрүнөт:
Кызматты өз алдынча колдонсо болот (мисалы, Docker аркылуу), бизде да бар , анда сиз маалымат кампасы менен интеграцияны орното аласыз, домениңизге CNAME кошуп, окуялардын саны боюнча статистиканы көрө аласыз. Биздин жакынкы пландарыбыз – бул веб-ресурстагы статистиканы гана эмес, ошондой эле тышкы маалымат булактарынан алынган маалыматтарды чогултуу жана аларды каалаган сактагычка сактоо мүмкүнчүлүгүн кошуу!
→
→
→
EventNative көйгөйлөрүңүздү чечүүгө жардам берсе, биз кубанычта болобуз!
Сурамжылоого катталган колдонуучулар гана катыша алышат. , өтүнөмүн.
Сиздин компанияңызда кандай статистикалык маалыматтарды чогултуу системасы колдонулат?
-
48,0%Google Analytics12
-
4,0%Сегмент 1
-
16,0%Дагы бир (комментарийге жаз)4
-
32,0%Сиздин кызматыңызды ишке ашырдым8
25 колдонуучу добуш берди. 6 колдонуучу добуш берүүдөн баш тартты.
Source: www.habr.com