Одоогийн байдлаар дэлхийн бараг бүх компани вэб нөөц дээр хэрэглэгчийн үйлдлийн талаарх статистик мэдээллийг цуглуулдаг. Урам зориг нь тодорхой байна - компаниуд өөрсдийн бүтээгдэхүүн / вэбсайтыг хэрхэн ашиглаж байгааг мэдэж, хэрэглэгчдийг илүү сайн ойлгохыг хүсдэг. Мэдээжийн хэрэг, зах зээл дээр энэ асуудлыг шийдэх олон тооны хэрэгслүүд байдаг - аналитик системээс эхлээд хяналтын самбар, график хэлбэрээр өгөгдөл өгдөг (жишээлбэл, ) Хэрэглэгчийн өгөгдлийн платформ руу шилжүүлэх бөгөөд энэ нь танд өөр өөр эх сурвалжаас мэдээллийг цуглуулах, нэгтгэх боломжийг олгодог (жишээлбэл, ).
Гэхдээ бид одоог хүртэл шийдэгдээгүй байгаа асуудлыг олсон. Ийнхүү төрсөн — нээлттэй эхийн аналитик үйлчилгээ. Бид яагаад өөрийн үйлчилгээгээ хөгжүүлэхээр явсан, энэ нь бидэнд юу өгсөн, эцэст нь юу болсон талаар (хэсэг кодын хамт) захын доор уншина уу.
Бид яагаад өөрсдийн үйлчилгээгээ хөгжүүлэх ёстой вэ?
Ерээд он, бид чадах чинээгээрээ амьд үлдсэн. 2019 онд бид API анхны хэрэглэгчийн мэдээллийн платформыг боловсруулсан kSense, энэ нь өөр өөр эх сурвалжаас (Facebook зар, Stripe, Salesforce, Google play, Google Analytics гэх мэт) өгөгдлийг нэгтгэж, өгөгдөлд илүү тохиромжтой дүн шинжилгээ хийх, хамаарлыг тодорхойлох гэх мэт боломжтой болсон. Олон хэрэглэгчид манай платформыг Google Analytics (цаашид GA) өгөгдөлд дүн шинжилгээ хийхэд ашигладаг болохыг бид анзаарсан. Бид зарим хэрэглэгчидтэй ярилцаж, GA ашиглан хүлээн авсан бүтээгдэхүүнийхээ аналитик өгөгдөл хэрэгтэй байгааг олж мэдсэн боловч мөн олон хүний хувьд GA Хэрэглэгчийн интерфейс нь тав тухтай байдлын стандарт биш юм. Бид хэрэглэгчидтэйгээ хангалттай ярилцаж, олон хүн Segment платформыг ашигладаг болохыг ойлгосон (дашрамд хэлэхэд хэдхэн хоногийн өмнө байсан). ).
Тэд өөрсдийн вэб нөөц дээр Segment javascript пикселийг суулгасан бөгөөд тэдний хэрэглэгчийн зан байдлын өгөгдлийг тодорхой мэдээллийн санд (жишээ нь Postgres) ачаалсан. Гэхдээ сегмент нь бас сул талтай байдаг - үнэ. Жишээлбэл, хэрэв вэб нөөц нь 90,000 MTU (сар бүр хянагддаг хэрэглэгчид) байвал кассчинд сар бүр ~ 1,000 доллар төлөх шаардлагатай болно. Гурав дахь асуудал бас байсан - зарим хөтчийн өргөтгөлүүд (AdBlock гэх мэт) аналитик цуглуулгыг хаасан. Хөтөчөөс http хүсэлтийг GA болон Segment домайн руу илгээсэн. Үйлчлүүлэгчдийнхээ хүсэлд үндэслэн бид бүрэн хэмжээний өгөгдлийг (түүвэрлэлтгүйгээр) үнэ төлбөргүй цуглуулдаг, өөрийн дэд бүтцээр ажиллах боломжтой аналитик үйлчилгээг бий болгосон.
Үйлчилгээ хэрхэн ажилладаг
Энэхүү үйлчилгээ нь гурван хэсгээс бүрддэг: javascript пиксел (бид үүнийг дараа нь бичгийн хэлбэрээр дахин бичсэн), серверийн хэсэг нь GO хэл дээр хэрэгжсэн бөгөөд Redshift болон BigQuery-ийг дотоод мэдээллийн сан болгон ашиглахаар төлөвлөж байсан (дараа нь тэд дараах дэмжлэгийг нэмсэн). Postgres, ClickHouse, Snowflake).
GA болон сегментийн үйл явдлын бүтцийг өөрчлөхгүй байхаар шийдсэн. Шаардлагатай бүх зүйл бол пикселийг суулгасан вэб нөөцөөс бидний арын хэсэгт бүх үйл явдлыг хуулбарлах явдал байв. Үүнээс харахад үүнийг хийх нь тийм ч хэцүү биш юм. 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 (thread) дотор Файл уншигч файлыг уншиж, дараа нь өгөгдлийг хөрвүүлж, тодорхойлно. Хүснэгтийн менежер хүснэгтийн схем шинэчлэгдсэн эсэхийг шалгасны дараа өгөгдлийг нэг багцаар мэдээллийн санд бичнэ. Дараа нь бид өгөгдлийн санд шууд өгөгдөл бичих боломжийг нэмсэн боловч бид энэ горимыг олон тооны бус үйл явдлуудад ашигладаг - жишээлбэл хөрвүүлэлт.
Нээлттэй эх сурвалж ба ирээдүйн төлөвлөгөө
Хэзээ нэгэн цагт үйлчилгээ нь бүрэн хэмжээний бүтээгдэхүүн шиг болж, бид үүнийг Нээлттэй эх сурвалжид оруулахаар шийдсэн. Одоогийн байдлаар 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