Event Schema Design — วาง Analytics Event ให้ Scale ได้ปี 2026

คู่มือ event schema design สำหรับทีม B2B — naming convention, property taxonomy, governance เพื่อให้ analytics event scale ได้โดยไม่พังภายหลัง

Event Schema คือกระดูกสันหลังของ Analytics — วาง Event Schema ยังไงให้ Scale ได้ปี 2026

Last updated: 2026-06-02

ทีม B2B ส่วนใหญ่เริ่ม tracking ด้วยการ “ยิง event ตามที่ dev สะดวก” — button_click, Click_CTA, cta-clicked, ButtonClicked ปนกันใน GA4 และ Mixpanel จนเปิด dashboard ทีไรต้องนั่งเดาว่า event ไหนคืออันเดียวกัน ผลลัพธ์คือ attribution พัง, funnel นับซ้ำ, และทีมการตลาดเลิกเชื่อข้อมูลของตัวเอง รากของปัญหานี้ไม่ได้อยู่ที่เครื่องมือ — มันอยู่ที่ event schema ที่ไม่ถูกออกแบบมาตั้งแต่วันแรก จากประสบการณ์ audit ลูกค้า B2B Thailand กว่า 40 บัญชี เราพบว่า 7 ใน 10 บัญชีต้อง re-implement tracking ทั้งหมดภายใน 18 เดือน เพราะ schema เดิม scale ไม่ได้ บทความนี้จะวางหลักการออกแบบ event schema ที่ใช้ได้จริงตั้งแต่ startup ไปจนถึงองค์กรพันคน

Key Takeaways: Event schema ที่ดีต้องมี (1) naming convention ที่บังคับใช้ได้ เช่น object_action snake_case (2) property taxonomy ที่แยก event property ออกจาก user property ชัดเจน (3) governance process ที่ทุก event ใหม่ต้องผ่าน review ก่อน deploy และ (4) tracking plan ที่เป็น single source of truth ระหว่าง product, marketing และ analytics — ทีมที่ออกแบบ 4 ส่วนนี้ตั้งแต่ต้นจะประหยัด re-implementation cost ได้ 60-80% ใน 2 ปีแรก

Event Schema คืออะไรและทำไมต้องออกแบบตั้งแต่วันแรก

Event schema คือเอกสาร (และ contract) ที่กำหนดว่า analytics event แต่ละตัวจะมีชื่ออะไร, ยิงตอนไหน, มี property อะไรบ้าง, แต่ละ property รับค่าแบบไหน และใครเป็นเจ้าของ พูดง่าย ๆ คือ “data model” ของพฤติกรรมผู้ใช้ — เป็นสิ่งเดียวกับที่ database schema เป็นต่อข้อมูล transactional

ความเข้าใจผิดที่พบบ่อยที่สุดคือคิดว่า schema คือสิ่งที่ “เกิดขึ้นเองในเครื่องมือ” จริง ๆ แล้ว GA4, Mixpanel, Amplitude, Segment ไม่ได้บังคับ schema ใด ๆ ทั้งสิ้น — มันรับทุก event ที่ส่งเข้ามาแล้วเก็บไว้ ปัญหาคือเมื่อเวลาผ่านไป 6 เดือน คุณจะมี event 200+ ตัวที่ไม่มีใครรู้ว่าตัวไหนใช้ได้ ตัวไหนเลิกใช้แล้ว

ทำไมทีม B2B ถึงควรสนใจมากกว่า B2C

B2B sales cycle ยาว 3-12 เดือน — หมายความว่าถ้า schema เปลี่ยน กลางทาง funnel ที่กำลังวัดอยู่จะ broken ทันที และคุณต้องรอ cohort ใหม่อีก 6 เดือนเพื่อมีข้อมูลที่ comparable ต่างจาก e-commerce ที่ cycle สั้น เปลี่ยน schema แล้วเดือนหน้าก็มีข้อมูลใหม่ครบ

สัญญาณว่า schema เดิมไม่ scale

• มี event ชื่อคล้ายกัน 3-4 ตัวที่ไม่มีใครรู้ความต่าง
• Property บางตัวเก็บได้บ้างไม่ได้บ้าง (เพราะ dev คนละทีมเข้าใจไม่ตรงกัน)
• เปิด funnel report แล้วตัวเลขไม่ตรงกับ CRM
• ต้องเขียน SQL ยาว 50 บรรทัดเพื่อ normalize event ก่อนใช้

หลักการตั้งชื่อ Event ที่ใช้ได้จริง

Naming convention คือเรื่องแรกที่ทีมต้อง align ก่อนยิง event แรก เพราะแก้ทีหลังแพงมาก — GA4 และ Mixpanel ไม่ allow ให้ rename event โดยไม่เสีย historical data

Format: object_action ใน snake_case

มาตรฐานที่ Segment, Amplitude และ Google Analytics 4 แนะนำคือ object_action ในรูปแบบ snake_case ตัวอย่างเช่น:

✅ ใช้	❌ หลีกเลี่ยง
signup_completed	SignupCompleted, signup-completed, Signup Completed
lead_form_submitted	submit_lead, formSubmit, Lead Form
pricing_page_viewed	view_pricing, pricing_view, PricingPageView
demo_requested	request_demo, demoRequest, Demo Click

เหตุผลที่เลือก object_action (ไม่ใช่ action_object) คือเมื่อ event เยอะขึ้น การ sort ตามตัวอักษรจะ group event ของ object เดียวกันไว้ใกล้กัน — lead_form_submitted, lead_form_viewed, lead_form_abandoned จะอยู่ติดกันใน dashboard

Past tense เสมอ

Analytics event บันทึก “สิ่งที่เกิดไปแล้ว” ใช้ past tense — submitted ไม่ใช่ submit, viewed ไม่ใช่ view กฎเล็กแต่ทำให้เอกสารและ query อ่านเป็นภาษาธรรมชาติ

Reserved words ห้ามใช้

GA4 มี reserved event names เช่น page_view, session_start, first_visit ห้ามตั้งชื่อ custom event ทับ และห้ามใช้คำเฉพาะ platform เช่น fb_, gtag_ เพราะจะชนกับ automatic events

Property Taxonomy — แยก Event Property กับ User Property

หลายทีมทำผิดตั้งแต่ต้นด้วยการเก็บทุกอย่างเป็น event property — รวมทั้ง user_email, company_size, industry ผลคือทุก event มี payload 30+ field และเมื่อต้องการเปลี่ยน “industry” ของลูกค้าต้องไป backfill ทุก event เก่า

Event Property vs User Property vs Group Property

• Event property — describe เฉพาะ event นั้น ๆ เช่น button_text, form_id, page_url, value
• User property — describe ตัวผู้ใช้ที่ persist ข้าม session เช่น user_role, subscription_tier, signup_date
• Group property (สำคัญสำหรับ B2B) — describe ของ company/account เช่น company_industry, employee_count, arr_band

GA4 มี user property, Mixpanel มี user + group, Amplitude มี user + account property การออกแบบให้ map ได้ทั้ง 3 ระบบตั้งแต่ต้นจะประหยัดเวลา migration มาก อ่านวิธี implement ใน GA4 + GTM + Conversion API B2B Setup Guide

Required vs Optional Properties

ทุก event ต้องระบุชัดว่า property ไหนเป็น required (ขาดไม่ได้) และ optional ตัวอย่าง schema ของ lead_form_submitted:

Property	Type	Required	Example
form_id	string	✅	contact_main_v2
form_location	string	✅	pricing_page
lead_source	string	✅	google_ads
utm_campaign	string	⚪	q2_b2b_demo
form_fields_filled	integer	⚪	5

Naming Property อย่างสม่ำเสมอ

• ใช้ snake_case เหมือน event
• หน่วยวัดอยู่ในชื่อ — duration_seconds, revenue_thb, file_size_kb ดีกว่า duration เฉย ๆ
• Boolean ขึ้นต้นด้วย is_ หรือ has_ — is_new_user, has_active_subscription

Governance — กระบวนการที่ทำให้ Schema อยู่รอด 3 ปี

Schema ที่ดีในเอกสาร แต่ไม่มี governance จะพังภายใน 6 เดือน เพราะทุกคนแอบเพิ่ม event โดยไม่ผ่าน review

Tracking Plan = Single Source of Truth

Tracking plan เป็นเอกสาร (Notion, Google Sheet, หรือ tool อย่าง Avo, Iteratively) ที่ระบุทุก event, ทุก property, owner, status (active/deprecated), และตัวอย่าง payload ทุกครั้งที่จะเพิ่ม event ใหม่ ต้องอัพเดท tracking plan ก่อน implement

Review Process

ขั้นต่ำที่ทีม B2B ควรมี:
1. PM/Marketing ขอ event ใหม่ ผ่าน template (เหตุผล, business question ที่ต้องตอบ)
2. Analytics lead review — ตรวจ naming, property, ซ้ำกับ event เดิมไหม
3. Dev implement ตาม spec ใน tracking plan
4. QA validate ใน staging ด้วย GTM Preview mode หรือ GA4 DebugView
5. Sign-off แล้วถึง deploy production

Deprecation Policy

Event ที่ไม่ใช้แล้ว อย่าลบทันที — mark เป็น deprecated ในเอกสาร และหยุดยิง แต่เก็บ historical data ไว้อย่างน้อย 14 เดือนเพื่อ year-over-year comparison สำหรับ B2B ที่ cycle ยาว ควรเก็บ 24 เดือน

ทีมที่จริงจังจะใช้ server-side tracking เป็น enforcement layer — ถ้า event ไม่ตรง schema, server จะ reject ทำให้ schema drift เกิดไม่ได้

ผิดพลาดที่พบบ่อย

จาก audit เราเจอ pattern เดิม ๆ ที่ทำให้ schema พัง 5 ข้อหลัก:

1. ตั้งชื่อตาม UI element แทน business action — red_button_clicked แย่กว่า demo_requested เพราะวันที่ designer เปลี่ยนปุ่มเป็นเขียว ชื่อ event จะกลายเป็น misleading
2. เก็บทุกอย่างเป็น event property — ทำให้ payload ใหญ่, query แพง, และ update user attribute ทีหลังลำบาก แก้ด้วยการแยก user/group property ตั้งแต่ต้น
3. Property ที่ free-form text — lead_source ที่รับค่าอะไรก็ได้ จะกลายเป็น Google, google, GoogleAds, google_ads, GA ภายใน 3 เดือน — ใช้ enum (รายการค่าที่อนุญาต) เสมอ
4. ไม่มี version ของ schema — เมื่อต้องเปลี่ยน schema ของ event เดิม ควรเพิ่ม schema_version: 2 แทนการแก้เงียบ ๆ
5. PM/Marketing ไม่มีส่วนร่วม — schema ที่ออกแบบโดย dev อย่างเดียวจะตอบ business question ไม่ได้ ต้องเริ่มจาก “เราอยากตอบคำถามอะไร” ก่อนเสมอ

Real-world Example

Placeholder: กรณีศึกษาจริงของลูกค้า Adsitec ที่ migrate event schema จาก legacy GTM setup ไปสู่ Segment-based architecture พร้อมตัวเลข before/after (event drift %, query time, attribution accuracy) จะถูกอัพเดทในบทความนี้หลังได้รับ approval จากลูกค้า — กำหนดอัพเดท Q3 2026

หากต้องการดู template tracking plan ที่ Adsitec ใช้กับลูกค้า B2B สามารถอ่านวิธี implement dashboard บน schema ที่ออกแบบดีแล้วใน Looker Studio Dashboard B2B Template

FAQ

Q: ควรเริ่มจาก event กี่ตัวสำหรับ B2B SaaS เริ่มต้น?
A: 15-25 event ก็เพียงพอสำหรับปีแรก ครอบคลุม acquisition (page view, form submit, demo request), activation (signup, first action), และ retention (key feature used, subscription change) อย่ายิงเยอะเกินจำเป็น — event ที่ไม่มีคนดูคือ tech debt

Q: GA4 กับ Mixpanel ควรใช้ schema เดียวกันไหม?
A: ใช่ — ออกแบบ schema กลางที่ใช้ได้ทั้ง 2 ระบบ แล้วใช้ Segment หรือ server-side container เป็น distribution layer ประหยัดเวลา maintain มากกว่าออกแบบแยก

Q: ควรเก็บ PII (email, phone) ใน event property ไหม?
A: ไม่ — ส่ง PII ไปยัง CRM หรือ identity resolution layer แยก ใช้ user_id (hashed) เป็น key เชื่อม สำหรับ Facebook CAPI ให้ส่ง PII ผ่าน Conversion API setup ที่ hash แล้วเท่านั้น

Q: เปลี่ยน naming convention กลางทาง ทำได้ไหม?
A: ทำได้แต่ราคาแพง — แนะนำให้ “freeze” event เดิม mark deprecated และเริ่มชุดใหม่ที่ schema ถูก ใช้ view layer ใน warehouse map ของเก่าให้ตรงของใหม่สำหรับ historical comparison

Q: ต้องมี data analyst เต็มเวลาเพื่อ maintain schema ไหม?
A: ไม่จำเป็นในปีแรก — PM หรือ marketing ops ที่เข้าใจ analytics สามารถเป็น schema owner ได้ ใช้ tracking plan + review process ที่ชัดเจนช่วยให้ governance อยู่ได้แม้ทีมเล็ก

สรุป + ขั้นตอนต่อไป

Event schema ไม่ใช่งานของ dev คนเดียว — มันคือ contract ระหว่าง product, marketing, และ data ที่ตัดสินว่าองค์กรจะตอบคำถามทาง business ได้แม่นยำแค่ไหน 3 takeaway ที่ควรเริ่มทำพรุ่งนี้:

1. เขียน tracking plan ของ event ที่มีอยู่ตอนนี้ — แม้จะมีแค่ 10 event ก็ตาม
2. กำหนด naming convention (object_action snake_case + past tense) แล้ว communicate กับทุกทีม
3. ตั้ง review process สำหรับ event ใหม่ — แม้จะเป็นแค่ Slack message ขออนุมัติก็ยังดีกว่าไม่มี

ขั้นตอนต่อไป ถ้าอยากต่อยอด schema ไปสู่ attribution ที่แม่นยำขึ้น แนะนำอ่าน Attribution Model B2B Guide 2026 หรือดูภาพรวมระบบ tracking ที่ MarTech Analytics & Tracking Guide เพื่อวาง roadmap ทั้งระบบให้ครบ