Ar hyn o bryd, mae bron pob cwmni yn y byd yn casglu ystadegau am weithredoedd defnyddwyr ar adnodd gwe. Mae'r cymhelliant yn glir - mae cwmnïau eisiau gwybod sut mae eu cynnyrch / gwefan yn cael ei ddefnyddio a deall eu defnyddwyr yn well. Wrth gwrs, mae yna nifer fawr o offer ar y farchnad i ddatrys y broblem hon - o systemau dadansoddi sy'n darparu data ar ffurf dangosfyrddau a graffiau (er enghraifft, ) i Lwyfan Data Cwsmer, sy'n eich galluogi i gasglu a chyfuno data o wahanol ffynonellau mewn unrhyw warws (er enghraifft ).
Ond daethom o hyd i broblem sydd heb ei datrys eto. Ganwyd felly — gwasanaeth dadansoddeg ffynhonnell agored. Darllenwch pam y penderfynon ni ddatblygu ein gwasanaeth ein hunain, beth roddodd i ni, a beth oedd y canlyniad terfynol (gyda darnau o god).
Pam dylen ni ddatblygu ein gwasanaeth ein hunain?
Y nawdegau oedd hi, fe wnaethon ni oroesi hyd eithaf ein gallu. 2019, fe wnaethom ddatblygu Llwyfan Data Cwsmer Cyntaf API kense, a oedd yn caniatáu agregu data o wahanol ffynonellau (hysbysebion Facebook, Stripe, Salesforce, Google play, Google Analytics, ac ati) ar gyfer dadansoddi data mwy cyfleus, nodi dibyniaethau, ac ati. Rydym wedi sylwi bod llawer o ddefnyddwyr yn defnyddio ein platfform dadansoddeg data, yn benodol Google Analytics (y cyfeirir ati o hyn ymlaen fel GA). Gwnaethom siarad â rhai defnyddwyr a chael gwybod bod angen eu data dadansoddeg cynnyrch, y maent yn ei dderbyn gan ddefnyddio GA, ond ac i lawer o GA Nid yw Rhyngwyneb Defnyddiwr yn safon cyfleustra. Cawsom ddigon o sgyrsiau gyda'n defnyddwyr a sylweddoli bod llawer hefyd yn defnyddio'r platfform Segment (a oedd, gyda llaw, ychydig ddyddiau yn ôl ).
Gosodwyd picsel javascript Segment ar eu hadnodd gwe a llwythwyd eu data ymddygiad defnyddwyr i gronfa ddata benodol (ee Postgres). Ond mae gan Segment ei minws hefyd - y pris. Er enghraifft, os oes gan adnodd gwe 90,000 MTU (defnyddwyr olrhain misol), yna mae angen i chi dalu ~ $ 1,000 y mis i'r ariannwr. Roedd trydydd problem hefyd - roedd rhai estyniadau porwr (fel AdBlock) yn rhwystro'r casgliad o ddadansoddeg. Anfonwyd ceisiadau http o'r porwr i'r parthau GA a Segment. Yn seiliedig ar awydd ein cleientiaid, rydym wedi creu gwasanaeth dadansoddeg sy'n casglu set lawn o ddata (heb samplu), yn rhad ac am ddim ac sy'n gallu gweithio ar ein seilwaith ein hunain.
Sut mae'r gwasanaeth yn gweithio
Mae'r gwasanaeth yn cynnwys tair rhan: picsel javascript (a ailysgrifennwyd gennym yn ddiweddarach i deipysgrif), rhan gweinydd a weithredwyd yn yr iaith GO, a'r bwriad oedd defnyddio Redshift a BigQuery fel cronfa ddata fewnol (yn ddiweddarach fe wnaethant ychwanegu cefnogaeth i Postgres , ClickHouse a Snowflake).
Strwythur y digwyddiadau Penderfynodd GA a Segment adael heb ei newid. Y cyfan oedd ei angen oedd i ddyblygu pob digwyddiad o'r adnodd gwe lle mae'r picsel wedi'i osod i'n backend. Fel mae'n digwydd, mae hyn yn hawdd i'w wneud. Roedd y picsel Javascript yn diystyru'r dull llyfrgell GA gwreiddiol gydag un newydd, a oedd yn dyblygu'r digwyddiad yn ein system.
//'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);
});
});
}
Gyda'r picsel Segment, mae popeth yn symlach, mae ganddo ddulliau nwyddau canol, a defnyddiwyd un ohonynt.
//'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.');
}
Yn ogystal â chopïo digwyddiadau, rydym wedi ychwanegu'r gallu i anfon json mympwyol:
//Отправка событий с произвольным 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'
});
Nesaf, gadewch i ni siarad am ochr y gweinydd. Dylai'r backend dderbyn ceisiadau http, eu llenwi â gwybodaeth ychwanegol, er enghraifft, data geo (diolch ar gyfer hyn) a'i gofnodi yn y gronfa ddata. Roeddem am wneud y gwasanaeth mor gyfleus â phosibl fel y gellir ei ddefnyddio heb fawr o gyfluniad. Rydym wedi gweithredu swyddogaeth pennu'r sgema data yn seiliedig ar strwythur y digwyddiad json sy'n dod i mewn. Diffinnir mathau o ddata gan werthoedd. Mae gwrthrychau nythu yn cael eu dadelfennu a'u lleihau i strwythur gwastad:
//входящий 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"
}Fodd bynnag, araeau yn cael eu trosi ar hyn o bryd yn syml i llinynnau oherwydd Nid yw pob cronfa ddata berthynol yn cefnogi meysydd ailadroddus. Mae hefyd yn bosibl newid enwau caeau neu eu dileu gan ddefnyddio rheolau mapio dewisol. Maent yn caniatáu ichi newid y sgema data os oes angen neu drosi un math o ddata i un arall. Er enghraifft, os yw maes json yn cynnwys llinyn gyda stamp amser (maes_3_sub_maes_1_sub_sub_maes_1 o'r enghraifft uchod), yna er mwyn creu maes yn y gronfa ddata gyda'r math o stamp amser, mae angen i chi ysgrifennu rheol fapio yn y ffurfweddiad. Mewn geiriau eraill, mae math data'r maes yn cael ei bennu yn gyntaf gan y gwerth json, ac yna mae'r rheol castio math (os yw wedi'i ffurfweddu) yn cael ei gymhwyso. Rydym wedi nodi 4 prif fath o ddata: STRING, FLOAT64, INT64 ac TIMESTAMP. Mae'r rheolau mapio a math o gastio yn edrych fel hyn:
rules:
- "/field_1/subfield_1 -> " #правило удаления поля
- "/field_2/subfield_1 -> /field_10/subfield_1" #правило переноса поля
- "/field_3/subfield_1/subsubfield_1 -> (timestamp) /field_20" #правило переноса поля и приведения типа
Algorithm ar gyfer pennu'r math o ddata:
- trosi strwythur json i strwythur gwastad
- pennu'r math o ddata o feysydd yn ôl gwerthoedd
- cymhwyso rheolau mapio a theipio castio
Yna o'r strwythur json sy'n dod i mewn:
{
"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"
}
}
bydd y sgema data yn cael ei gasglu:
"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
Roeddem hefyd yn meddwl y dylai'r defnyddiwr allu ffurfweddu rhaniad neu rannu data yn y gronfa ddata yn unol â meini prawf eraill a gweithredu'r gallu i osod enw'r tabl gyda chysonyn neu mewn cyfluniad. Yn yr enghraifft isod, bydd y digwyddiad yn cael ei gadw i dabl gydag enw wedi'i gyfrifo yn seiliedig ar werthoedd y meysydd product_type a _timestamp (er enghraifft cyflenwadau_2020_10):
tableName: '{{.product_type}}_{{._timestamp.Format "2006_01"}}'
Fodd bynnag, gall strwythur digwyddiadau sy'n dod i mewn newid yn ystod amser rhedeg. Rydym wedi gweithredu algorithm i wirio'r gwahaniaeth rhwng strwythur tabl presennol a strwythur digwyddiad sy'n dod i mewn. Os canfyddir gwahaniaeth, bydd y tabl yn cael ei ddiweddaru gyda meysydd newydd. I wneud hyn, defnyddiwch yr ymholiad SQL patch:
#Пример для Postgres
ALTER TABLE "schema"."table" ADD COLUMN new_column character varyingpensaernïaeth
Pam fod angen i chi ysgrifennu digwyddiadau i'r system ffeiliau, ac nid dim ond eu hysgrifennu'n uniongyrchol i'r gronfa ddata? Nid yw cronfeydd data bob amser yn dangos perfformiad uchel gyda nifer fawr o fewnosodiadau (). I wneud hyn, mae Logger yn ysgrifennu digwyddiadau sy'n dod i mewn i ffeil ac eisoes mewn goroutine (edau) ar wahân Mae darllenydd ffeil yn darllen y ffeil, yna mae'r trawsnewidiad a'r diffiniad o'r sgema data yn digwydd. Ar ôl i'r rheolwr Tabl sicrhau bod sgema'r tabl yn gyfredol, bydd y data'n cael ei ysgrifennu i'r gronfa ddata mewn un swp. Yn dilyn hynny, fe wnaethom ychwanegu'r gallu i ysgrifennu data yn uniongyrchol i'r gronfa ddata, ond rydym yn defnyddio'r modd hwn ar gyfer digwyddiadau nad ydynt yn llawer - er enghraifft, trawsnewidiadau.
Ffynhonnell Agored a chynlluniau ar gyfer y dyfodol
Ar ryw adeg, dechreuodd y gwasanaeth edrych fel cynnyrch cyflawn a phenderfynon ni ei ryddhau i Open Source. Ar hyn o bryd, mae integreiddiadau gyda Postgres, ClickHouse, BigQuery, Redshift, S3, Snowflake wedi'u rhoi ar waith. Mae pob integreiddiad yn cefnogi moddau llwytho data swp a ffrydio. Ychwanegwyd cefnogaeth ar gyfer ceisiadau trwy API.
Mae’r cynllun integreiddio presennol yn edrych fel hyn:
Er y gellir defnyddio'r gwasanaeth yn annibynnol (er enghraifft defnyddio Docker), mae gennym ni hefyd , lle gallwch chi sefydlu integreiddiad gyda warws data, ychwanegu CNAME i'ch parth a gweld ystadegau ar nifer y digwyddiadau. Ein cynlluniau ar unwaith yw ychwanegu'r gallu i agregu nid yn unig ystadegau o adnodd gwe, ond hefyd data o ffynonellau data allanol a'u cadw i unrhyw storfa o'ch dewis!
→
→
→
Byddwn yn falch os bydd EventNative yn helpu i ddatrys eich problemau!
Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. os gwelwch yn dda.
Pa system casglu ystadegau a ddefnyddir yn eich cwmni?
-
48,0%Google Analytics12
-
4,0%Segment1
-
16,0%Arall (ysgrifennwch yn y sylwadau) 4
-
32,0%Wedi rhoi eich gwasanaeth ar waith8
Pleidleisiodd 25 o ddefnyddwyr. Ataliodd 6 o ddefnyddwyr.
Ffynhonnell: hab.com