แถบตัวกรอง
Location → Screen → Camera
ช่วงเวลา / online / degraded / offline
System Architecture
กล้อง / คลิป → คุณลักษณะ → target matching → ประมูล → content ที่ cache ในจอ → หลักฐาน playback / attention → billing review / refund
อ่านสถานะก่อน: แผนภาพด้านล่างเป็น design เป้าหมาย ไม่ใช่บริการที่ติดตั้งครบแล้ว ปัจจุบันมีหน้า simulation และ OpenPAR local inference แยกกัน ข้อมูล campaign / billing ยังอยู่ในหน่วยความจำหน้าเว็บ ไม่มีฐานข้อมูลกลางถาวร
Operator dashboard / CRUD design
ส่วนนี้เป็นแบบหน้าจอและ workflow ที่เสนอ ยังไม่ใช่ dashboard ที่เชื่อมอุปกรณ์จริงหรือบันทึก CRUD ลงฐานข้อมูล
ภาพรวมการปฏิบัติงาน
จอพร้อมรับ paid slot · cache ไม่พร้อม
คิวคำสั่งค้าง · AI observation เก่า
คลิปกำลังเล่น / slot ถัดไป
พื้นที่ทำงาน
รายการอุปกรณ์ → รายละเอียด → แก้ไข
Decision trace / playback events
ประวัติการเปลี่ยนค่าและเหตุขัดข้อง
| รายการ | Create / Read | Update | Delete / ข้อจำกัด |
|---|---|---|---|
| Location / zone | เพิ่มสถานที่ โซน และดูจอที่สังกัด | ชื่อ ที่ตั้ง เวลาเปิดบริการ; ราคาผ่านสิทธิ์ pricing | Archive หากมีประวัติ ห้ามลบข้อมูลที่บิลอ้างอิง |
| Screen / camera | ลงทะเบียนอุปกรณ์และดูสถานะ | Mapping กล้อง–จอ, schedule, maintenance mode | Deactivate / revoke credential; ไม่ล้าง playback history |
| Content cache | ดู manifest / version / readiness; สั่ง prefetch | Retry ไฟล์เสียหรือดาวน์โหลด version ใหม่ | Evict เฉพาะไฟล์ไม่กำลังเล่นและไม่ถูกจอง; คง fallback ไว้ |
| Campaign operations | ดู campaign ที่มีสิทธิ์และเหตุผลเข้า/ไม่เข้าแข่ง | พักการส่งงานเมื่อมี incident พร้อมเหตุผล; ไม่แก้ bid ของลูกค้าเงียบ ๆ | Archive ตาม policy ไม่ลบ charge / evidence reference |
| คำสั่งจอ | ดู acknowledgement และคำสั่งค้าง | Cancel เฉพาะคิวที่ยังไม่เริ่ม; retry ด้วย ID เดิม | ไม่ตัดคลิปกลางคันเพื่อแทรก campaign ใหม่; ไม่ถือ cancel เป็น refund |
ก่อนบันทึก: ตรวจสิทธิ์ location, validation, version conflict และผลกระทบต่อคิว แสดงสรุปการเปลี่ยนค่าและขอยืนยันคำสั่งที่กระทบอุปกรณ์ ทุก mutation ต้องตรวจสิทธิ์ที่ backend ไม่ใช่แค่ซ่อนปุ่ม
System Owner dashboard / revenue design
มุมมองเจ้าของแพลตฟอร์มทั้งระบบ แยกจาก Customer ที่เห็นเฉพาะ campaign ของตน และ Operator ที่ดูแลเฉพาะ location ที่ได้รับสิทธิ์
Financial overview
Gross charges → refunds → net billed
Cash collected / receivables แยกต่างหาก
Pending review และวงเงินที่กันไว้
Business performance
รายได้ราย location / screen / customer
Display fee เทียบ attention fee
Paid fill rate และ refund rate
Governance
สิทธิ์ผู้ใช้ / การอนุมัติราคา
Floor price ของ popular zone
Audit trail / reconciliation / incident
| Metric | นิยามที่เสนอ | ข้อควรระวัง |
|---|---|---|
| Gross charges | ผลรวมรายการ charge ที่ลงบัญชีแล้วในช่วงเวลา | ไม่รวม reserved budget หรือแค่ชนะประมูล |
| Net billed | Gross charges − refunds ที่ลงบัญชีในช่วงเวลาเดียวกัน | ไม่เท่ากับเงินสดรับหรือกำไร; refund อาจอ้างถึง charge ของงวดก่อน |
| Cash / receivables | เงินรับที่ยืนยันแล้ว / ยอดค้างรับจากระบบ invoice และ payment | ยังไม่มี payment integration ห้ามใช้ simulated charge แทนเงินจริง |
| Platform earnings | คำนวณได้เมื่อมีสัญญา revenue share, ภาษี และค่าใช้จ่ายที่กำหนด | ยังไม่กำหนด commission จึงไม่สร้างตัวเลขกำไรขึ้นเอง |
| Paid fill rate | จำนวน slot ที่เล่น paid content สำเร็จ ÷ จำนวน slot ที่เปิดขายได้ | กำหนด slot และ maintenance exclusions ให้เหมือนกันทุก location |
| Refund / attention rate | ยอด refund ÷ gross charges; attention-qualified completed plays ÷ completed plays | แยก cohort และช่วงเวลา; ตัวหารศูนย์แสดง N/A ไม่ใช่ 0% |
ตัวกรอง: ช่วงเวลาและ timezone, location, customer, campaign และ variant; drill down จากยอดรวม → campaign → playback → ledger → หลักฐานตามสิทธิ์ แสดงสกุลเงินเสมอ และไม่รวมหลายสกุลโดยไม่มีอัตราแลกเปลี่ยนที่ระบุ
Owner เปลี่ยนนโยบายได้ตามสิทธิ์ แต่ไม่แก้ ledger ย้อนหลังโดยตรง การแก้ยอดต้องเป็นรายการชดเชยที่ตรวจสอบได้ ส่วน invoice, payment และ revenue share เป็น backlog ยังไม่เพิ่มโมเดลข้อมูลหรือหน้ารับชำระเงินในครั้งนี้
System health check / observability design
แยก alive (process ยังทำงาน), ready (รับงานได้) และ fresh (ข้อมูลยังใหม่) จอ online ไม่ได้แปลว่าไฟล์พร้อมหรือ AI ทันเวลา
| ส่วนระบบ | สัญญาณตรวจสุขภาพ | เมื่อผิดปกติ |
|---|---|---|
| Camera / gateway | Last frame time, frame age, decode errors, heartbeat | หยุดใช้ observation หมดอายุ ไม่ถือว่าไม่มีคนเพียงเพราะกล้องขาด |
| AI worker | Model loaded, queue age, inference p95/p99, failure rate, memory | แสดง degraded / not ready; จำกัดคิวและข้ามเฟรมเก่า ไม่ส่งผลเก่าเป็นผลใหม่ |
| Player / cache | Heartbeat, disk free, checksum, playback progress, dropped frames | ไม่เริ่ม paid slot หากไฟล์ไม่พร้อม ใช้ local fallback และแจ้ง operator |
| Backend / DB | API error rate, decision latency, transaction failures, connection saturation | หยุด paid allocation เมื่อกันงบไม่ได้; health probe ต้องไม่สร้าง charge จริง |
| Event delivery | Unacknowledged commands, retry backlog, oldest pending event, duplicates | ส่งซ้ำแบบ idempotent และตรวจ event ที่ค้าง ไม่สร้าง playback ใหม่จาก retry |
| Financial consistency | Expired reservations, overspend, refunds เกิน charge, ledger reconciliation | แจ้งระดับ critical / ระงับ settlement ที่ผิดปกติและให้ตรวจ ไม่แก้ยอดอัตโนมัติโดยไร้หลักฐาน |
สถานะหน้าจอ: Healthy / Degraded / Offline / Unknown พร้อม last checked และเหตุผล; ไม่มี telemetry ต้องเป็น Unknown ไม่ใช่สีเขียว ตั้ง threshold ตาม SLO ที่ทดสอบจริง และใช้ grace period ลดการแจ้งเตือนซ้ำ
Health console ที่เสนอ: ภาพรวมทุก location → เลือก node → timeline ของ incident → logs / metrics ตาม correlation ID → acknowledge / recovery note; ไม่แสดงภาพผู้ชม token หรือข้อมูลลูกค้าใน public health endpoint
ปัจจุบันมี health endpoint ของ OpenPAR local service เท่านั้น ส่วน fleet monitoring และ alerting นี้ยังเป็น design ไม่ใช่ผลตรวจสุขภาพสด
Distributed / centralized boundary diagram
กระจายการรับภาพ ประมวลผล และเล่นไฟล์ใกล้จุดใช้งาน แต่รวมการตัดสินงบและบัญชีไว้ส่วนกลาง ไม่ทำฐานยอดเงินแยกอิสระที่แต่ละจอ
Edge · Location A
Camera A1 / A2
↓ frames
Gateway / optional AI worker
↓ local observation buffer
Player A1 / A2 + disk cache
Edge · Location B
Camera B1 / B2
↓ frames
Gateway / optional AI worker
↓ local observation buffer
Player B1 / B2 / B3 + disk cache
↑ observations / readiness / playback evidence / heartbeat
↓ versioned content manifests / playback commands / configuration
ผ่าน authenticated network · acknowledgement + retry + expiry
Central control plane
Customer / Operator / Owner UI
↓ API + role / location permissions
Campaign → match / auction → reservation
Measurement → billing / review
Central data authority
Relational DB: campaign, budget, ledger
Media / evidence store: files
Telemetry: metrics / logs
Logical authority เดียว; backup / replica ไม่ใช่บัญชีอิสระอีกชุด
Shared AI compute · ทางเลือก
Gateway → bounded inference queue
→ workers CPU / GPU → observations
ถ้า edge ไม่พอ ส่งเฉพาะเฟรมที่จำเป็นตามนโยบาย ไม่ต้องย้าย video playback มาที่ server
| ข้อออกแบบ | Centralized | Distributed |
|---|---|---|
| ข้อมูลที่ตัดสินเงิน | Atomic budget reservation และ ledger write ที่ backend / DB กลาง | ปลายทางเก็บเพียงคำสั่งและหลักฐานรอ sync ไม่ถือยอด cache เป็นยอดเงินจริง |
| ความเร็ว | ตัดสินจาก metadata / observation ไม่รอ stream content | ดาวน์โหลดล่วงหน้า เล่นจาก disk; inference ขนานแต่คุม queue age |
| เมื่อขาดการเชื่อมต่อ | ยังไม่ settle หากหลักฐานไม่ครบ; reconcile หลังกลับมา | เล่นคลิปที่เริ่มแล้วจนจบ บันทึกผล ใช้ house content สำหรับ slot ใหม่ |
| ขยายระบบ | เพิ่ม API / worker replicas ได้ แต่ต้องคง atomic reservation และ idempotency | เพิ่ม location / gateway โดยแยกคิวและจำกัดทรัพยากรต่อกล้อง |
Diagram นี้เป็น deployment design ไม่ได้ติดตั้ง cluster, replica, monitoring หรือฐานข้อมูลจริงเพิ่มเติมใน Lab
Use cases · ใครทำอะไรกับระบบ
Customer / เจ้าของ content
กรอกข้อมูลลูกค้า → สร้าง campaign → เลือก segment / จอ / bid → เลือก content A/B → ดูผลและตรวจบิล
Operator / ผู้ดูแลจอ
กำหนด location และกล้องที่สัมพันธ์กับจอ → ตรวจ cache / สถานะอุปกรณ์ → ดูเหตุผลที่ campaign ชนะหรือถูกตัดออก
Reviewer / ผู้ตรวจบิล
ดูหลักฐานหลังเล่น → ตรวจ target และ attention → approve หรือ reject พร้อมเหตุผล → ลง refund
| ID / ผู้เริ่ม | เงื่อนไขก่อนเริ่ม | เส้นทางหลัก / ผลลัพธ์ | ทางเลือก / ข้อยกเว้น |
|---|---|---|---|
| UC01 · Customer ซื้อ campaign | ข้อมูลลูกค้าครบ และมีสิทธิ์บัญชี | ระบุ target, จอ, ราคาสองชั้น, งบ และ A/B → บันทึก campaign | ข้อมูลไม่ครบ / A และ B ซ้ำ / งบไม่พอ → ให้แก้ก่อนเปิด campaign |
| UC02 · Camera event เลือก content | Observation ยังใหม่ และมีจอที่ mapped ไว้ | ตรวจ eligible → match → bid → กันงบ → เลือก variant → ส่งคำสั่งจอ | ไม่มีตัวเลือกผ่าน / cache ไม่พร้อม → house content ไม่คิดเงิน |
| UC03 · Player เล่นและส่งหลักฐาน | คำสั่งไม่หมดอายุ ไฟล์พร้อม และมี reservation | รอจบคลิปเดิม → เล่นจาก cache → ส่ง started / completed และหลักฐาน | ไฟล์เสีย → failed; network ขาด → เก็บ event รอส่งซ้ำ |
| UC04 · Customer / Reviewer ตรวจบิลย้อนหลัง | เล่นแล้ว มี charge และ evidence ที่ได้รับสิทธิ์ดู | ตรวจ target / attention → approve หรือ reject + refund → คง charge เดิมไว้ | หลักฐานไม่ครบ → pending review; refund ซ้ำ → ไม่ลงยอดซ้ำ |
| UC05 · Customer เปรียบเทียบ A/B | มี assignment และผล playback | ดู completed / attention / gross / refund / net แยก variant และจอ | ตัวอย่างน้อย → รายงานว่ายังสรุปไม่ได้ ไม่ประกาศผู้ชนะอัตโนมัติ |
| UC06 · Operator จัดการหลาย location | อุปกรณ์ลงทะเบียนและผูกสิทธิ์แล้ว | ตั้ง camera–screen mapping / floor price → ตรวจ readiness และสุขภาพระบบ | จอ offline → หยุด paid slot ใหม่และติดตามการกู้คืน |
ผู้เดินผ่านเป็นแหล่ง observation ไม่ใช่ผู้ใช้ที่ต้อง login; สถานะสิทธิ์และการบันทึกถาวรข้างต้นเป็นแบบระบบเต็ม ยังไม่ใช่ความสามารถที่เปิดใช้ครบใน Lab
Technology stack · ที่ใช้จริง / เป้าหมาย
คง HTML / CSS / JavaScript ของ Lab และแยก Python AI ออกไป ไม่เปลี่ยน frontend framework เพียงเพื่อเพิ่มระบบหลังบ้าน
| Layer | ปัจจุบันใน Lab | แบบระบบเต็มที่เสนอ |
|---|---|---|
| Web UI | HTML + CSS + native JavaScript ES modules | ใช้ stack เดิมเรียก backend API; แยกมุมมอง customer / operator / reviewer ตามสิทธิ์ |
| Business logic | JavaScript simulation ใน browser | Backend กลางเป็น modular monolith; framework ยังไม่เลือก ย้ายกฎตัดสินและธุรกรรมออกจาก browser |
| AI service | Python + PyTorch / PromptPAR; HTTP server จาก Python standard library บน loopback | AI workers แยก process พร้อม bounded queue; production API ต้องเพิ่ม authentication และ supervision ไม่เปิด demo server สู่อินเทอร์เน็ต |
| Inference hardware | CPU adapter; MiVOLO ยังไม่เชื่อม | GPU server / edge accelerator เป็นตัวเลือก ต้อง benchmark รุ่นโมเดลและ runtime ก่อนเลือก |
| Database | schema.mjs เป็น proposed schema; campaign / billing เป็น memory state | Central relational DB พร้อม transaction, foreign keys, unique idempotency keys; MariaDB เป็นตัวเลือกที่เคยหารือ ยังไม่ติดตั้งหรือเลือกเป็นข้อสรุป |
| Media / evidence | Predefined assets และ simulated evidence | File / object storage ส่วนกลาง + local disk cache ที่ player; DB เก็บ metadata และ references ไม่เก็บวิดีโอทั้งไฟล์ |
| Device / transport | Browser video / webcam และ local HTTP inference | Raspberry Pi player + device agent เป็นเป้าหมาย; HTTPS API สำหรับผล/ไฟล์ และช่องส่งคำสั่งที่มี acknowledgement (protocol ยังไม่เลือก) |
| Testing / documentation | Node.js built-in test runner; ERD สร้างจาก schema.mjs | เพิ่ม API integration, concurrency, recovery, load และ privacy tests ก่อนใช้งานจริง |
ตารางนี้เป็นการแยกข้อเท็จจริงจากทางเลือก ไม่ใช่คำรับรอง performance หรือรายการ dependency ที่ติดตั้งแล้ว อ่านเหตุผลฝั่ง AI ที่ Reference and Motivation
Subsystems · แยกความรับผิดชอบ
Observation → Audience interpretation → Decision → Delivery → Measurement → Billing
Campaign management ป้อนเงื่อนไขให้ Decision · Device management ป้อน readiness ให้ Delivery
| Subsystem | รับเข้า → ส่งออก | ขอบเขตที่เป็นเจ้าของ |
|---|---|---|
| S1 · Customer & campaign | Customer detail / targeting / bids / A/B → campaign configuration | ตรวจข้อมูลและ version ของเงื่อนไข ไม่ตัดสินผล AI |
| S2 · Perception | ภาพรายกล้อง → attributes / confidence / เวลา / model version | Inference และคุณภาพ observation ไม่คิดราคา |
| S3 · Segment interpretation | Attributes → segment matches / unknown | กฎ multi-label / temporal aggregation แยกจาก weights ของโมเดล |
| S4 · Decision & allocation | Segments + campaign + readiness + งบ → winner / reservation / decision trace | Eligibility, partial match, per-screen bid และ A/B assignment |
| S5 · Device & delivery | Creative manifest / playback command → readiness / playback events | Camera mapping, local cache, transition และ event retry |
| S6 · Measurement | Playback + observation → evidence / qualified attention / A/B metrics | แยกเวลาอยู่หน้าจอจากเวลามองจริง ไม่ลง refund เอง |
| S7 · Billing & review | Verified outcome + frozen price → charge / review / refund | Ledger, idempotency, ยอดสุทธิและ audit trail |
Subsystem คือขอบเขตของงาน ไม่ได้หมายความว่าต้อง deploy เป็น 7 microservices เริ่มรวม business modules ใน backend เดียวได้ และแยก AI / player ตามภาระงาน
User interface · หน้าจอและเส้นทางผู้ใช้
Customer journey
Customer details → Campaign editor → Screen pricing → Content A/B → Summary / evidence → Dispute
เปิด Campaign Sales / A/BOperator journey
Location / device status → Camera mapping → Cache readiness → Decision trace → Playback health
เปิด Decision SimulatorResearch journey
Webcam / upload clip → Attributes → เปรียบเทียบกฎ segment → Reference → Architecture / ERD
เปิด OpenPAR / Webcam| หน้า / panel | องค์ประกอบที่ควรเห็น | สถานะ |
|---|---|---|
| Campaign dashboard | ข้อมูลลูกค้า, งบ, bid รายจอ 2 ชั้น, A/B, billing summary, evidence และ reject/refund หลังเล่น | มีใน simulation; ยังไม่ใช่ระบบหลายบัญชีหรือซื้อขายเงินจริง |
| Decision Simulator | เลือกคนจำลอง → ดู 5 จอ → full / partial / exclusion reason และราคาที่ชนะ | มีแล้ว ใช้ predefined segments |
| OpenPAR / Webcam | Webcam / clip input, preview, attributes และ uncertainty | มี local inference; ยังไม่เชื่อมเข้าสู่ auction |
| Location / device console | แผนผังกล้อง–จอ, online / offline, cache version, storage, error และ command acknowledgement | ยังไม่สร้าง เป็น UI เป้าหมาย |
| Reviewer workspace | รายการ pending, จำกัดการเห็น evidence ตามสิทธิ์, เหตุผล reject, refund history | มีขั้นตอนจำลองใน dashboard; หน้าเฉพาะ reviewer และ role enforcement ยังไม่มี |
| References / Architecture | งานอ้างอิง, motivation, design, stack และ ERD จาก schema กลาง | มีแล้ว เป็นเอกสารและแบบที่เสนอ |
UI states ที่ต้องแยก: ไม่มีข้อมูล, กำลังโหลด, AI ไม่พร้อม, ผลไม่แน่ใจ, cache ไม่พร้อม, งบไม่พอ, จอ offline, เล่นแล้วรอตรวจ และ refund สำเร็จ ห้ามแสดงคำว่า “เรียกเก็บแล้ว” ตั้งแต่ชนะประมูล
การเพิ่มหัวข้อในหน้านี้ยังไม่ได้สร้าง route, service หรือฐานข้อมูลใหม่ เมื่อ implement ส่วนที่เสนอ ต้องเพิ่ม schema / migration และการทดสอบสิทธิ์พร้อมกัน
01 · System / deployment design
แยกงานที่ต้องอยู่ใกล้กล้องและจอ ออกจากการตัดสินใจและบัญชีกลาง
Location A
กล้อง A1 / A2 → Edge gateway
ส่งเฟรมที่เลือกให้ AI worker
TV A1 / A2 มี local content cache
Location B
กล้อง B1 / B2 → Edge gateway
ประมวลผลขนานกับ Location A
TV B1 / B2 / B3 มี local content cache
AI workers · LAN / server
Detect → track → crop → attributes
ส่งผลพร้อม camera, เวลา และ model version ไม่ส่งวิดีโอต่อให้ระบบประมูล
↓ observation events / cache readiness ↑ playback commands
Central backend
Campaign / targeting / auction
กันงบร่วม / A/B / playback verification
Billing / review / refund
Central database
ข้อมูลลูกค้า campaign และราคาแต่ละจอ
Decision trace, playback, charge / refund
ฐานบัญชีเดียวเป็นแหล่งอ้างอิงหลัก
Media / evidence storage
ไฟล์ content และหลักฐานแยกจาก relational DB
DB เก็บข้อมูลอ้างอิงไฟล์และสิทธิ์เข้าถึง · TV ดาวน์โหลดล่วงหน้า
กล้องหนึ่งตัวอาจดูแลหลายจอ และจอหนึ่งอาจรับข้อมูลจากหลายกล้อง ต้องกำหนด mapping และหน้าต่างเวลารวม observation ก่อนตัดสิน ไม่ถือว่าทุกกล้องหมายถึงผู้ชมใหม่เสมอไป
02 · AI pipeline / segment design
- รับภาพWebcam / clip / camera gateway
- หาและติดตามคนPerson detector + track ภายในกล้อง
- แยก attributesOpenPAR; MiVOLO เป็นตัวเลือกเสริม
- รวมผลตามเวลาลด label สลับไปมา / เก็บ unknown
- สร้าง segmentAge + gender label + clothing rules
ขอบเขตปัจจุบัน: OpenPAR รับ crop กลางภาพ ยังไม่มี detector / tracker หลายคนหรือการจับคู่คนข้ามกล้อง อายุจาก PA100K ยังเป็น <18 / 18–60 / >60 ส่วน MiVOLO ยังไม่เชื่อม
สัญญาข้อมูลที่เสนอ: camera_id, observed_at, track reference เฉพาะกล้อง, attribute scores, model version และคุณภาพภาพ ไม่รวมชื่อหรือการยืนยันตัวตน ให้กฎ segment แยก version จากโมเดลเพื่ออธิบายผลย้อนหลัง
ผู้เดินด้วยกันเป็นเพียงข้อสังเกต ไม่เพียงพอจะยืนยันครอบครัว พี่น้อง หรือคู่รัก ดู โมเดลและ motivation
03 · Decision / auction / A/B design
- รวมผู้ชมของจอใช้ observation ที่ยังไม่หมดอายุ
- ตรวจสิทธิ์เข้าแข่งเวลา / location / hard target / cache / งบ
- คำนวณ matchALL / ANY ภายในกลุ่มเงื่อนไข
- จัดอันดับ + กันงบBid ของจอนี้ × match score
- เลือก A หรือ Bสุ่มหลัง campaign ชนะ
| เรื่อง | กติกาที่เสนอ | เหตุผลที่ต้องบันทึก |
|---|---|---|
| Overlapping segments | ตรวจแต่ละเงื่อนไขกับคนเดียวกันก่อน ไม่เอาอายุของคน A รวมเสื้อของคน B ให้เกิด full match; campaign เดียวไม่เพิ่มสิทธิ์ซ้ำเพราะเข้าหลาย segment | อธิบาย full / partial และ label ที่ไม่ตรง |
| ราคาแต่ละจอ | ใช้ bid และ floor ของ location / screen นั้น Popular zone ตั้ง floor ต่างกันได้ ไม่คูณเพิ่มโดยซ่อนจากผู้ซื้อ | เก็บราคาและกติกา ณ เวลาตัดสิน |
| คะแนน | Baseline: score = bid_display × M; hard constraints ต้องผ่านก่อน ส่วน weighted confidence match เป็นงานทดลองต่อ | แยก match score, auction score และเงินจริง |
| คะแนนเท่ากัน | ใช้กฎคงที่: full match → bid สูงกว่า → campaign ID ตามลำดับ | ตัดสินซ้ำได้จาก input เดิม |
| A/B readiness | ข้อเสนอ: ต้องมีทั้ง A และ B พร้อมที่จอจึงเข้า experiment; สุ่ม 50:50 หลังชนะ ไม่เอาราคาแข่งกันระหว่าง variant | ลด selection bias จากไฟล์ใดไฟล์หนึ่งไม่พร้อม |
คนเดียวผ่าน 5 กล้องอาจได้ content ต่างกัน เพราะราคา location, readiness และงบร่วมต่างกัน “ไฟล์ไม่พร้อม” คือเหตุผลที่ไม่เข้าแข่ง ไม่ใช่คะแนน match ต่ำ ต้องแสดง exclusion reason แยกจากแพ้ราคา
04 · Content cache / transition design
- เตรียม contentตรวจ format / duration / version
- ดาวน์โหลดล่วงหน้าไฟล์ลง local storage ของจอ
- ตรวจความพร้อมChecksum + เปิดอ่านได้ → READY
- รับคำสั่งเล่นระบุ creative version ที่พร้อมแล้ว
- เล่นจาก cacheไม่ stream ตอนพบเป้าหมาย
READY → QUEUED → PLAYING → COMPLETED
QUEUED → CANCELLED / EXPIRED · PLAYING → FAILED
คนใหม่เดินผ่านขณะเล่น: ประเมินสำหรับ slot ถัดไป ไม่ตัดกลางคลิป ให้เปลี่ยนเมื่อจบคลิปหรือจุด transition ที่ผู้สร้างอนุญาต หากผลเป้าหมายหมดอายุให้ประเมินใหม่ก่อนเริ่ม slot ถัดไป
ไฟล์เสียหรือพื้นที่เต็มให้รายงาน NOT READY และพักสิทธิ์ creative นั้น ห้ามลบไฟล์ที่กำลังเล่น ไม่มีตัวเลือกพร้อมให้เล่น house content ที่ cache ไว้โดยไม่คิดเงิน
05 · Evidence / billing / dispute design
- ชนะและกันงบDisplay + attention สูงสุด
- จอรายงานเล่นจริงStarted / completed + creative version
- สรุปหลักฐานTarget snapshot + ช่วงเวลามอง
- ลง chargeเรียกเก็บตามเงื่อนไขหลังเล่น
- ตรวจย้อนหลังApprove หรือ reject + refund
charge = display_price + attention_price × I(stopped AND watch_seconds > clip_length / 2)
ใช้ราคาที่ snapshot ตอนตัดสิน เก็บเวลามองเฉพาะช่วงเล่นของจอนั้น และเก็บวิธีวัด: การหยุดยืนไม่ใช่หลักฐานว่ามองจอจริง ค่าเท่าครึ่งคลิปยังไม่เข้าเงื่อนไข ใน Lab การมองเป็นค่าจำลอง ยังไม่มี gaze verification
ไม่มี reject ก่อนเล่น: การยกเลิกคิวเป็นการคืนวงเงินกันไว้ ไม่ใช่ refund หลังมี charge แล้วจึงตรวจความตรงของหลักฐานและคืนเงินเป็น ledger รายการใหม่ ไม่ลบ charge เดิม
กติกาต้นแบบ: เรียกเก็บเมื่อเล่นจบ เล่นไม่สำเร็จไม่ควรสรุปว่า completed อัตโนมัติ กรณีหลักฐานไม่ครบให้รอตรวจสอบ; retry event เดิมต้องไม่คิดซ้ำหรือคืนเงินซ้ำ และยอด refund รวมไม่เกิน charge
A/B report: แยก assignments, completed plays, qualified attention, gross charge, refunds และ net charge ของ A/B รายจอ รายงานรายการที่ถูก reject แยกด้วย ไม่ซ่อนประวัติ และอย่าตัดสินผู้ชนะจาก sample เล็กโดยไม่มีช่วงความไม่แน่นอน
06 · Parallel / distributed / failure design
| สถานการณ์ | การออกแบบ | สิ่งที่วัด |
|---|---|---|
| หลายกล้องพร้อมกัน | แยกคิว inference ตาม camera ใช้คิวมีขอบเขต เลือกเฟรมล่าสุดเมื่อค้าง ไม่สะสมภาพเก่าจนตัดสินช้า; รวมผลเข้าจอตาม mapping | Queue age, dropped frames, observation latency |
| หลายจอใช้ campaign เดียว | ให้ backend กันงบใน DB transaction แบบ atomic ก่อนส่งคำสั่ง มี reservation expiry และกติกาคืนงบ | Overspend ต้องเป็นศูนย์ / lock wait / decision p95 |
| ส่งซ้ำ / ลำดับสลับ | Event ID + playback ID + state transition checks; เก็บ event แล้วส่งต่อด้วย transactional outbox เมื่อทำ backend จริง | Duplicate suppression / missing acknowledgements |
| เครือข่ายขาด | เล่นคลิปที่เริ่มแล้วให้จบ เก็บหลักฐานรอส่งซ้ำ ไม่เริ่ม paid auction ใหม่หากไม่ได้รับสิทธิ์กันงบ; ใช้ house content แทน | Offline duration / log backlog / recovery time |
| คำสั่งมาช้า | กำหนดอายุคำสั่งและ observation; จอปฏิเสธคำสั่งหมดอายุ แล้ว backend คืน reservation อย่างปลอดภัย | Expired commands / stale decisions |
| ฐานข้อมูลกลางล่ม | หยุดตัดสิน paid slot ใหม่ ไม่ใช้ยอดงบใน browser เป็นแหล่งจริง กู้คืนจาก backup และตรวจ ledger ก่อนเปิดรับงาน | Recovery test / reconciliation differences |
เริ่มจาก backend แบบ modular monolith + AI workers แยก process แล้วค่อยแยกบริการเมื่อ benchmark ชี้คอขวด ไม่จำเป็นต้องทำทุก module เป็น microservice ตั้งแต่แรก Raspberry Pi เป็น cache/player ก่อน; on-device AI ยังต้องทดสอบ
07 · Access / privacy / verification design
Customer
จัดการ campaign และดูบิลเฉพาะบัญชีตัวเอง ส่งข้อโต้แย้งหลังเล่นแล้ว
Operator / reviewer
ดูแลจอ ตรวจหลักฐาน และอนุมัติ refund ตามสิทธิ์ ทุกการแก้ไขมี audit trail
Device
ยืนยันตัวจอ ส่ง event ได้เฉพาะจอที่ได้รับสิทธิ์ ไม่แก้ bid งบ หรือ ledger โดยตรง
เก็บ evidence เท่าที่จำเป็น กำหนดระยะเก็บและสิทธิ์ก่อนใช้ภาพคนจริง ปกปิดใบหน้าที่ไม่จำเป็นต่อการตรวจ หลีกเลี่ยง public URL ถาวร และไม่เปิดหลักฐานให้ลูกค้ารายอื่น ข้อมูลผ่านเครือข่ายต้องมี authentication และ encryption
สิทธิ์ผู้ใช้ อุปกรณ์ outbox และนโยบายเก็บหลักฐานเป็น design backlog ยังไม่ใช่ระบบที่ implement แล้ว ต้องเพิ่ม schema / migrations ที่เกี่ยวข้องพร้อม implementation และให้ ERD อัปเดตจากแหล่งเดียว
ERD และรายการตารางสร้างจาก schema.mjs ชุดเดียวกัน เพิ่มตารางหรือความสัมพันธ์ใน schema แล้วแสดงที่นี่อัตโนมัติเมื่อโหลดหน้าใหม่ · ยังไม่เชื่อม introspection ฐานข้อมูลจริงหรือรัน migration
ขอบเขตระบบที่เสนอ
ปลายทางเก็บ content และหลักฐานการเล่น · บริการ AI ส่ง attributes พร้อมคะแนนและเวอร์ชันโมเดล · Backend กลางดูแลลูกค้า campaign งบ และบัญชี · ข้อมูล AI ยังไม่เชื่อมกับการประมูลในต้นแบบ
ราคา 2 ชั้น: ค่าแสดง + ค่ามองเพิ่มเมื่อหยุดมอง > ครึ่งคลิป · A/B สุ่มหลัง campaign ชนะ · ตรวจบิลหลังเล่นจบเท่านั้น · ledger เก็บ charge และ refund คนละรายการ ไม่ลบยอดเดิม ใช้ idempotency key ป้องกันซ้ำ
เมื่อสร้างฐานข้อมูลจริงต้องบังคับ variant ให้ตรง experiment จำกัด refund ไม่เกินยอดเรียกเก็บ และใช้ transaction เมื่อกัน/คืนงบ · reviewer_id รอเชื่อมบัญชีผู้ใช้
ERD / คลิกชื่อตารางเพื่อดูความสัมพันธ์
ลูกศรอ่านจากตารางต้นทางไปตารางที่อ้างอิง · N → 1 = หลายรายการอ้างถึงหนึ่งรายการ · 0..1 หมายถึงมีหรือไม่มีก็ได้