Eins og er, safna nánast hvert fyrirtæki í heiminum tölfræði um aðgerðir notenda á vefforriti. Hvatinn er skýr - fyrirtæki vilja vita hvernig vara/vefsíða þeirra er notuð og skilja notendur sína betur. Auðvitað er mikill fjöldi tækja á markaðnum til að leysa þetta vandamál - allt frá greiningarkerfum sem veita gögn í formi mælaborða og grafa (td. ) til viðskiptavinagagnavettvangs, sem gerir þér kleift að safna og safna gögnum frá mismunandi aðilum í hvaða vöruhúsi sem er (td. ).
En við fundum vandamál sem hefur ekki verið leyst ennþá. Þannig fæddist — opinn uppspretta greiningarþjónusta. Lestu um hvers vegna við ákváðum að þróa okkar eigin þjónustu, hvað hún gaf okkur og hver niðurstaðan var (með kóða).
Af hverju ættum við að þróa okkar eigin þjónustu?
Það var á tíunda áratugnum, við lifðum af eins og við gátum. 2019, þróuðum við API First Customer Data Platform kSense, sem gerði það mögulegt að safna saman gögnum frá mismunandi aðilum (Facebook auglýsingar, Stripe, Salesforce, Google play, Google Analytics o.s.frv.) fyrir þægilegri gagnagreiningu, auðkenningu ósjálfstæðis o.s.frv. Við höfum tekið eftir því að margir notendur nota vettvang okkar fyrir gagnagreiningu sérstaklega Google Analytics (hér eftir GA). Við ræddum við nokkra notendur og komumst að því að þeir þurfa greiningargögnin fyrir vöruna sína sem þeir fá með GA, en og fyrir marga er GA notendaviðmótið ekki staðall um þægindi. Við áttum nóg af samtölum við notendur okkar og komumst að því að margir voru líka að nota Segment pallinn (sem, við the vegur, var bara um daginn ).
Þeir settu upp Segment javascript pixla á vefforritið sitt og gögnum um hegðun notenda þeirra var hlaðið inn í tilgreindan gagnagrunn (til dæmis Postgres). En Segment hefur líka sína galla - verðið. Til dæmis, ef vefforrit hefur 90,000 MTU (mánaðarlega rakta notendur), þá þarftu að borga ~1,000 $ á mánuði til gjaldkera. Það var líka þriðja vandamálið - sumar vafraviðbætur (eins og AdBlock) lokuðu á söfnun greiningar vegna þess að... http beiðnir frá vafranum voru sendar til GA og Segment lénanna. Byggt á óskum viðskiptavina okkar höfum við búið til greiningarþjónustu sem safnar fullkomnu safni af gögnum (án sýnatöku), er ókeypis og getur unnið á okkar eigin innviðum.
Hvernig þjónustan virkar
Þjónustan samanstendur af þremur hlutum: javascript pixla (sem við endurskrifuðum síðar í vélriti), miðlarahlutinn er útfærður á GO tungumálinu og fyrirhugað var að nota Redshift og BigQuery sem innbyggðan gagnagrunn (síðar bættu þeir við stuðningi við Postgres, ClickHouse og Snowflake).
Ákveðið var að halda uppbyggingu GA og Segment atburðanna óbreyttri. Allt sem þurfti var að afrita alla atburði úr vefforritinu þar sem pixlin er sett upp í bakenda okkar. Eins og það kemur í ljós er þetta ekki erfitt að gera. Javascript díllinn hnekkti upprunalegu GA bókasafnsaðferðinni með nýrri, sem afritaði atburðinn inn í kerfið okkar.
//'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);
});
});
}
Með Segment pixlinum er allt einfaldara; það hefur millihugbúnaðaraðferðir, eina sem við notuðum.
//'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.');
}
Auk þess að afrita atburði höfum við bætt við möguleikanum á að senda handahófskennt 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'
});
Næst skulum við tala um miðlarahlutann. Bakendinn ætti að samþykkja http beiðnir, fylla þær með viðbótarupplýsingum, til dæmis landfræðilegum gögnum (takk fyrir þetta) og skrá það í gagnagrunninn. Við vildum gera þjónustuna eins þægilega og mögulegt er svo hægt sé að nota hana með lágmarks stillingum. Við höfum innleitt virknina við að ákvarða gagnaskema byggt á uppbyggingu komandi json atburðar. Gagnagerðir eru skilgreindar með gildum. Hreiður hlutir eru niðurbrotnir og minnkaðir í flata byggingu:
//входящий 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"
}Hins vegar er fylki sem stendur einfaldlega breytt í strengi vegna þess Ekki styðja allir venslagagnagrunnar endurtekna reiti. Einnig er hægt að breyta reitaheitum eða eyða þeim með valkvæðum kortlagningarreglum. Þeir gera þér kleift að breyta gagnaskemanu ef þörf krefur eða breyta einni gagnategund í aðra. Til dæmis, ef json reitur inniheldur streng með tímastimpli (field_3_sub_field_1_sub_sub_field_1 úr dæminu hér að ofan), til þess að búa til reit í gagnagrunninum með tímastimplagerðinni þarftu að skrifa kortlagningarreglu í uppsetninguna. Með öðrum orðum, gagnategund reitsins er fyrst ákvörðuð af json gildinu og síðan er gerð steypureglunnar (ef hún er stillt) notuð. Við höfum bent á 4 helstu gagnategundir: STRING, FLOAT64, INT64 og TIMESTAMP. Kortlagningar- og tegundarsteypureglurnar líta svona út:
rules:
- "/field_1/subfield_1 -> " #правило удаления поля
- "/field_2/subfield_1 -> /field_10/subfield_1" #правило переноса поля
- "/field_3/subfield_1/subsubfield_1 -> (timestamp) /field_20" #правило переноса поля и приведения типа
Reiknirit til að ákvarða gagnategund:
- breyta json uppbyggingu í flata uppbyggingu
- ákvarða gagnategund reita með gildum
- að beita korta- og tegundarsteypureglum
Síðan frá komandi json uppbyggingu:
{
"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"
}
}
gagnaskemað verður aflað:
"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
Við töldum líka að notandinn ætti að geta stillt skiptingu eða skipt gögnum í gagnagrunninum eftir öðrum forsendum og útfærðum möguleikann á að stilla töfluheitið með fasta eða í uppsetningunni. Í dæminu hér að neðan verður atburðurinn vistaður í töflu með nafni sem er reiknað út frá gildum vörutegundar og _tímastimpils (til dæmis vistir_2020_10):
tableName: '{{.product_type}}_{{._timestamp.Format "2006_01"}}'
Hins vegar getur uppbygging komandi atburða breyst á keyrslutíma. Við höfum innleitt reiknirit til að athuga muninn á uppbyggingu núverandi töflu og uppbyggingu komandi atburðar. Ef munur finnst verður taflan uppfærð með nýjum reitum. Til að gera þetta, notaðu plástur SQL fyrirspurnina:
#Пример для Postgres
ALTER TABLE "schema"."table" ADD COLUMN new_column character varyingarkitektúr
Af hverju þarf að skrifa atburði í skráarkerfið en ekki bara að skrifa þá beint í gagnagrunninn? Gagnagrunnar standa sig ekki alltaf vel þegar fjallað er um mikinn fjölda innskots (). Til að gera þetta skrifar Logger komandi atburði í skrá og í sérstakri goroutine (þráð) les skráalesari skrána, síðan er gögnunum breytt og ákvörðuð. Eftir að töflustjórinn hefur gengið úr skugga um að töfluskemað sé uppfært verða gögnin skrifuð í gagnagrunninn í einni lotu. Í kjölfarið bættum við við möguleikanum á að skrifa gögn beint í gagnagrunninn, en við notum þennan hátt fyrir atburði sem eru ekki margir - til dæmis viðskipti.
Open Source og áætlanir um framtíðina
Á einhverjum tímapunkti fór þjónustan að líta út eins og fullgild vara og við ákváðum að gefa hana út á Open Source. Eins og er hafa samþættingar við Postgres, ClickHouse, BigQuery, Redshift, S3, Snowflake verið innleiddar. Allar samþættingar styðja bæði lotu- og streymisham við hleðslu gagna. Bætti við stuðningi við beiðnir í gegnum API.
Núverandi samþættingarkerfi lítur svona út:
Þó að hægt sé að nota þjónustuna sjálfstætt (til dæmis með því að nota Docker), höfum við það líka , þar sem þú getur sett upp samþættingu við gagnavöruhús, bætt CNAME við lénið þitt og skoðað tölfræði um fjölda viðburða. Strax áætlanir okkar eru að bæta við getu til að safna saman ekki aðeins tölfræði úr vefforriti, heldur einnig gögnum frá ytri gagnaveitum og vista þau í hvaða geymslu sem þú velur!
→
→
→
Við munum vera ánægð ef EventNative hjálpar til við að leysa vandamálin þín!
Aðeins skráðir notendur geta tekið þátt í könnuninni. , takk.
Hvaða tölfræðisöfnunarkerfi er notað í fyrirtækinu þínu?
-
48,0%Google Analytics 12
-
4,0%Hluti 1
-
16,0%Annað (skrifaðu í athugasemdir)4
-
32,0%Innleiddi þjónustu þína8
25 notendur kusu. 6 notendur sátu hjá.
Heimild: www.habr.com