Қазіргі уақытта әлемдегі әрбір дерлік компания веб-ресурстағы пайдаланушы әрекеттері туралы статистиканы жинайды. Мотивация түсінікті – компаниялар өз өнімінің/веб-сайтының қалай пайдаланылатынын білгісі келеді және өз пайдаланушыларын жақсырақ түсінгісі келеді. Әрине, нарықта бұл мәселені шешу үшін көптеген құралдар бар - бақылау тақталары мен графиктер түрінде деректерді беретін аналитикалық жүйелерден бастап (мысалы, ) кез келген қоймадағы әртүрлі көздерден деректерді жинауға және біріктіруге мүмкіндік беретін Тұтынушы деректері платформасына (мысалы, ).
Бірақ біз әлі шешілмеген мәселені таптық. Осылайша дүниеге келді — ашық бастапқы талдау қызметі. Неліктен біз өз қызметімізді дамытуды шешкеніміз, ол бізге не берді және соңғы нәтиже қандай болды (код бөліктерімен) туралы оқыңыз.
Неліктен біз өз қызметімізді дамытуымыз керек?
Тоқсаныншы жылдар еді, қолдан келгенше аман қалдық. 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).
GA және Segment оқиғаларының құрылымын өзгеріссіз қалдыру туралы шешім қабылданды. Тек пиксель орнатылған веб-ресурстағы барлық оқиғаларды серверге көшіру қажет болды. Белгілі болғандай, мұны істеу қиын емес. 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
Біз сонымен қатар пайдаланушы дерекқордағы деректерді басқа критерийлер бойынша бөлуді конфигурациялау немесе бөлу мүмкіндігі болуы керек деп ойладық және кесте атауын тұрақты немесе тұрақты мәнмен орнату мүмкіндігін іске асырдық. конфигурацияда. Төмендегі мысалда оқиға өнім_түрі және _уақыт белгісі өрістерінің мәндері негізінде есептелген аты бар кестеге сақталады (мысалы жабдықтау_2020_10):
tableName: '{{.product_type}}_{{._timestamp.Format "2006_01"}}'
Дегенмен, кіріс оқиғаларының құрылымы орындау уақытында өзгеруі мүмкін. Біз бар кесте құрылымы мен кіріс оқиға құрылымы арасындағы айырмашылықты тексеру үшін алгоритмді енгіздік. Егер айырмашылық табылса, кесте жаңа өрістермен жаңартылады. Ол үшін SQL патч сұрауын пайдаланыңыз:
#Пример для Postgres
ALTER TABLE "schema"."table" ADD COLUMN new_column character varyingсәулет
Неліктен оқиғаларды тікелей дерекқорға жазбай, файлдық жүйеге жазу керек? Дерекқорлар кірістірулердің көп санымен жұмыс істегенде әрқашан жақсы жұмыс істей бермейді (). Ол үшін Logger кіріс оқиғаларын файлға жазады және бөлек goroutine (ағын) Файлды оқу құралы файлды оқиды, содан кейін деректер түрлендіріледі және анықталады. Кесте менеджері кесте схемасының жаңартылғанына көз жеткізгеннен кейін деректер бір топтамада дерекқорға жазылады. Кейіннен біз деректерді тікелей дерекқорға жазу мүмкіндігін қостық, бірақ біз бұл режимді көп емес оқиғалар үшін пайдаланамыз - мысалы, түрлендіру.
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 пайдаланушы қалыс қалды.
Ақпарат көзі: www.habr.com