สิ่งที่ผมได้เรียนรู้จากการทดสอบความถี่ของ Popunder เทียบกับการมีส่วนร่วมของผู้ใช้

ตอนแรกผมคิดว่าความถี่ของ popunder จะมี trade-off ที่เห็นได้ชัด: แสดงโฆษณาน้อยลงเพื่อรักษาประสบการณ์ผู้ใช้ หรือแสดงบ่อยขึ้นเพื่อเพิ่มรายได้จน engagement เริ่มลดลง แต่พออยู่ใน production ความสัมพันธ์ไม่ได้เรียบง่ายขนาดนั้น

หลังจากเพิ่มความถี่ในเว็บแอป production ตัวหนึ่ง ผมคาดว่าจะเห็นจุดเปลี่ยนชัดเจนในข้อมูล engagement แต่ metric แบบ aggregate กลับยังเคลื่อนไหวอยู่ในช่วงแกว่งรายวันเดิมโดยประมาณ บางวันดีขึ้น บางวันแย่ลง แต่ผมไม่เห็นการลดลงแบบต่อเนื่องที่เริ่มชัดเจนพร้อมนโยบายใหม่

สุดท้ายผมเก็บค่าดังนี้:

ดีเลย์เริ่มต้น: 45 วินาที
Cooldown ขั้นต่ำหลัง popunder สำเร็จ: 4 นาที

ผมยังเก็บ frequency window ที่อนุญาต event สำเร็จได้สูงสุดหนึ่งครั้งในช่วงสี่นาทีเดียวกัน:

const policy = {
  initialDelaySeconds: 45,
  cooldownSeconds: 240,
  windowSeconds: 240,
  maxEventsPerWindow: 1,
};

นี่เป็น pseudocode สำหรับอธิบายแนวคิด ไม่ผูกกับผู้ให้บริการโฆษณา SDK แอป หรือ deployment ใดโดยเฉพาะ สิ่งที่น่าสนใจกว่ารายละเอียด implementation คือ policy ที่อยู่เบื้องหลัง

จริง ๆ แล้วมีการตัดสินใจเรื่องความถี่สองอย่าง

ช่วงแรกผมมองคำถามว่า popunder สองครั้งควรห่างกันกี่นาที แต่ต่อมาพบว่านั่นเป็น abstraction ที่ไม่เหมาะ อย่างน้อยมีสองการตัดสินใจ: ดีเลย์ก่อนโอกาสโฆษณาครั้งแรก และช่วงขั้นต่ำก่อนโอกาสครั้งต่อ ๆ ไป

สองช่วงเวลานี้ไม่เหมือนกัน ผู้เข้าชมใหม่ยังไม่รู้ว่าผลิตภัณฑ์มีประโยชน์กับเขาหรือไม่ ส่วนผู้ใช้ที่ engaged แล้วได้ตัดสินใจไปพอสมควร ดังนั้นผมจึงให้การรบกวนครั้งแรกมีการปกป้องมากกว่าครั้งถัดไป

ทำไมผมจึงหยุด monetization ช่วงวินาทีแรกอย่างก้าวร้าวเกินไป

ดีเลย์เริ่มต้นที่สั้นลงทำให้ผู้เข้าชมมีสิทธิ์เร็วขึ้นและสร้างโอกาส ad event มากขึ้น ในเชิงกลไกนี่เป็นเรื่องจริง แต่ตรรกะนี้ละเลยว่า monetization เกิดขึ้นเมื่อไร

ถ้าโฆษณาเกิดแทบทันทีหลังผู้ใช้เข้ามา มันจะกลายเป็นส่วนหนึ่งของการประเมินเว็บไซต์ครั้งแรก แต่ถ้าผู้ใช้มีเวลาที่ไม่ถูกรบกวนเพื่อทำความเข้าใจและใช้งานผลิตภัณฑ์ก่อน กลไกโฆษณาแบบเดิมจะถูกพบในบริบทที่ต่างออกไป

เดิมผมใช้ดีเลย์สั้นกว่านี้ ก่อนจะขยับเป็น 45 วินาที ซึ่งยังถือว่าค่อนข้างเร็วและไม่ได้ออกแบบให้เป็นการตั้งค่าแบบอนุรักษนิยม จุดประสงค์คือแยกช่วงเริ่มต้นของ visit ออกจากโอกาส monetization แรก ผมเริ่มมอง 45 วินาทีนี้เป็นเวลาที่ผลิตภัณฑ์ใช้พิสูจน์คุณค่า ไม่ใช่ inventory โฆษณาที่เสียไป

45 วินาทีคือ threshold ไม่ใช่เวลาที่โฆษณาต้องเกิด

การครบดีเลย์หมายถึงผู้ใช้เริ่ม eligible เท่านั้น ไม่ได้แปลว่าโฆษณาจะปรากฏอัตโนมัติที่ 00:45 Event จริงยังต้องอาศัย interaction ที่เข้าข่าย ผู้ใช้อาจ eligible ที่ 00:45 และเกิด popunder แรกตอน 01:03 หลัง action ที่เหมาะสมครั้งถัดไป

Cooldown ก็เหมือนกัน สี่นาทีหมายความว่า event ถัดไปยังไม่ eligible จนกว่าจะครบสี่นาทีหลัง event สำเร็จก่อนหน้า ไม่ได้หมายถึงมีโฆษณาอัตโนมัติทุกสี่นาที ดังนั้น interval ที่ตั้งไว้เป็นค่าขั้นต่ำ และระยะจริงอาจนานกว่านั้น

ช่วงระหว่างการแสดงซ้ำสำคัญกว่าดีเลย์ครั้งแรก

เมื่อพอใจกับดีเลย์แรกแล้ว repeat cadence ก็กลายเป็นตัวแปรที่สำคัญกว่า Cooldown ที่ยาวช่วยลดแรงกดดันจากโฆษณา แต่ก็อาจทำให้ผู้ใช้ engaged จำนวนมากไม่มีโอกาสครั้งที่สองเลย

ผมต้องการสองเงื่อนไขพร้อมกัน: ผู้ใช้ที่ใช้งานต่อควรมีโอกาสจริงในการสร้าง monetization event ใหม่ และระหว่าง event ต้องยังมีช่วงใช้งานผลิตภัณฑ์แบบต่อเนื่องที่มีความหมาย

ค่าที่ผมเก็บไว้คือสี่นาที เมื่อดีเลย์แรกอยู่ที่ 45 วินาที จุด eligibility ที่เร็วที่สุดในทางทฤษฎีคือประมาณ 00:45, 04:45, 08:45 และ 12:45 Event จริงอาจเกิดช้ากว่านี้เพราะยังต้องมี qualifying interaction

ทำไมสี่นาทีต่างจากการ maximize impressions อย่างเดียว

การลด cooldown สร้างโอกาสเชิงทฤษฎีมากขึ้น ถ้า metric เดียวคือจำนวนโอกาสโฆษณาต่อผู้ใช้ ช่วงที่สั้นกว่าย่อมดีกว่า แต่ผลิตภัณฑ์มีมูลค่าโฆษณาได้ต่อเมื่อยังมีมูลค่าสำหรับผู้ใช้

monetization เพิ่ม
-
ความเสียหายต่อพฤติกรรม
=
มูลค่าสุทธิ

สี่นาทีให้ช่วงใช้งานผลิตภัณฑ์ตามปกติที่มีความหมาย โดยที่ popunder ใหม่ไม่สามารถเกิดขึ้นได้ สำหรับผม invariant นี้สำคัญกว่าคำว่า “หนึ่งครั้งทุกสี่นาที”

หลัง monetization event ผู้ใช้จะมีเวลาหลายนาทีที่ event แบบเดียวกันครั้งถัดไปเกิดไม่ได้

ผมคาดว่า engagement จะลดลงให้เห็นชัด

ก่อน deployment สมมติฐานหลักของผมคือการเพิ่มความถี่โฆษณาจะสร้าง before-and-after drop ที่ชัดใน analytics ถ้าเกิดขึ้นจริง ผมคงมีเหตุผลหนักแน่นที่จะลดความเข้มของ policy

แต่ aggregate engagement กลับยังแกว่งคล้ายเดิม ผมไม่เห็น baseline ใหม่ที่ต่ำลง หรือชุดค่าที่อ่อนลงต่อเนื่องหลังปรับความถี่ Failure mode ที่ผมคาดว่าจะใหญ่พอให้เห็นได้ชัดกลับไม่ปรากฏอย่างชัดเจน

สิ่งที่ผมสามารถอ้างได้จริง

ผมไม่สามารถพูดว่าโฆษณาไม่มีผลเลย ผู้ใช้ไม่รำคาญ retention ไม่เปลี่ยนแปลงเลย หรือ configuration นี้เหมาะที่สุดในทุกกรณี ค่าเฉลี่ย aggregate เพียงค่าเดียวพิสูจน์เรื่องเหล่านั้นไม่ได้

ข้อสรุปที่แรงที่สุดซึ่งข้อมูลของผมรองรับมีขอบเขตแคบกว่านั้น:

หลังเพิ่มความถี่ ผมไม่พบการลดลงแบบชัดเจนและต่อเนื่องของ aggregate engagement ที่เกินกว่าความผันผวนปกติซึ่งมีอยู่แล้วก่อนหน้า

ข้อความนี้ยังเปิดพื้นที่ให้กับผลกระทบขนาดเล็ก ความแตกต่างระหว่างกลุ่มผู้ใช้ และพฤติกรรมที่ค่าเฉลี่ยค่าเดียวซ่อนไว้ ผมทดสอบว่า configuration นี้ยอมรับได้พอที่จะเก็บไว้หรือไม่ ไม่ใช่ว่าผมหาค่า optimum ที่ใช้ได้ทุกที่หรือยัง

ค่าเฉลี่ยที่คงที่อาจซ่อนพฤติกรรมที่ต่างกันมาก

ค่า aggregate average ที่แทบไม่เปลี่ยนอาจเกิดจากหลายสถานการณ์ ทุกคนอาจมีพฤติกรรมคล้ายเดิม บางคนอาจออกเร็วขึ้นในขณะที่อีกกลุ่มอยู่นานขึ้น กลุ่มเล็กอาจได้รับผลลบแต่เล็กเกินกว่าจะขยับค่าเฉลี่ย หรืออาจมีผลลบจริงแต่เล็กกว่าความผันผวนรายวันปกติ

ดังนั้นผมมองค่าเฉลี่ยที่คงที่เป็น warning signal ที่มีประโยชน์ ไม่ใช่หลักฐานว่าไม่มีผลกระทบ

Engagement ไม่เท่ากับระยะเวลาของ visit แบบตรงตัว

ผมยังหลีกเลี่ยงการมอง analytics engagement metric เป็นระยะเวลาเฉลี่ยของ session แบบเป๊ะ ๆ Active engagement ขึ้นกับนิยามของระบบ analytics และไม่จำเป็นต้องเท่ากับเวลาที่ tab เปิดอยู่ ผู้ใช้อาจสลับ focus กลับมาใหม่ภายหลัง หรือ navigate ในแบบที่ทำให้แนวคิดง่าย ๆ ว่า “time on site” ทำให้เข้าใจผิด

ผมจึงไม่ใช้สูตรว่า “average engagement คือ X ดังนั้น popunder ถัดไปต้องเกิดก่อน X” ผมใช้ metric เป็นสัญญาณเชิงทิศทาง: หลังการเปลี่ยนแปลง ผลิตภัณฑ์ดูอ่อนลงอย่างมีนัยสำคัญหรือไม่? ใน aggregate level ที่ผมเฝ้าดู คำตอบคือไม่

Cooldown กับ frequency window เกี่ยวข้องกัน แต่ไม่เหมือนกัน

Implementation ใช้ทั้ง cooldown 240 วินาที และ window 240 วินาทีที่อนุญาต event สำเร็จสูงสุดหนึ่งครั้ง โดยมากแล้วซ้ำหน้าที่กัน แต่สื่อ constraint ต่างกันเล็กน้อย

Cooldown บอกว่าอย่าให้ event ใหม่จนกว่าจะผ่านเวลาพอจากครั้งก่อน ส่วน window บอกว่าอย่าให้มี event สำเร็จมากกว่าหนึ่งครั้งในช่วงที่กำหนด ผมเก็บทั้งสองไว้เพื่อให้ invariant ที่ตั้งใจชัดเจน แม้ integration จะตีความ mechanism ใด mechanism หนึ่งต่างออกไป

Popunder ที่สำเร็จสองครั้งต้องไม่เกิดห่างกันน้อยกว่าสี่นาที

หนึ่ง event ต่อ window ไม่ได้แปลว่าหนึ่ง event ต่อ visit

ค่าอย่าง maxEventsPerWindow = 1 ไม่จำเป็นต้องหมายถึงมีโฆษณาเพียงครั้งเดียวตลอดเวลาที่ผู้ใช้อยู่บนเว็บไซต์ Scope ของมันคือ window ที่ตั้งไว้ เมื่อ window สิ้นสุดก็เริ่ม window ใหม่ได้ และ 1 ก็ไม่ได้หมายถึง user action หนึ่งครั้ง แต่หมายถึง monetization event ที่สำเร็จหนึ่งครั้งในช่วงนั้น

ทุกวันนี้เวลารีวิว frequency logic ผมถามสามข้อ: counter นับอะไร อะไรเป็นตัว reset และ reset window ยาวเท่าไร ถ้าไม่รู้ทั้งสามอย่าง ค่า raw อย่าง 1 แทบไม่มีความหมาย

ผมแยก policy ออกจาก implementation เฉพาะ provider

พฤติกรรมที่ต้องการ reuse สามารถอธิบายได้โดยไม่เปิดเผย script, identifier หรือ parameter name เฉพาะของ vendor:

function isEligible(state, now) {
  if (!state.hasShownFirstEvent) {
    return now - state.arrivalTime >= 45_000;
  }

  return now - state.lastEventTime >= 240_000;
}

นี่เป็น pseudocode เพื่ออธิบาย ไม่ใช่ production source code Provider, SDK และ deployment architecture เปลี่ยนได้ แต่ policy ทนทานกว่า: ปกป้องช่วงต้นของ visit อนุญาต monetization หลังเริ่มมีการใช้งานจริง บังคับ hard cooldown และค่อย repeat หลังจากนั้น

Build ผ่านกับพฤติกรรมถูกต้องเป็นคนละเรื่อง

Typechecker, linter และ production build ตรวจสอบคุณสมบัติทางเทคนิคได้หลายอย่าง แต่ไม่ได้พิสูจน์ว่า advertising timeline ใน browser ทำงานถูกต้อง Feature นี้ต้องมี behavioral validation เพิ่มด้วย

1. เปิด browser ในสถานะสะอาด
2. Interact ก่อนหมด initial delay: ต้องไม่มี popunder
3. รอให้เลย initial delay
4. ทำ eligible interaction: popunder แรกอาจเกิดได้
5. Interact ต่อก่อน cooldown จบ: ต้องไม่มี popunder ที่สอง
6. รอให้ cooldown หมด
7. Interact อีกครั้ง: ตอนนี้ popunder ถัดไปอาจเกิดได้

Build ที่สำเร็จกับ behavioral test ที่สำเร็จตอบคนละคำถาม และทั้งคู่สำคัญ

ประสบการณ์โฆษณารวมสำคัญกว่า placement ใด placement หนึ่ง

ระบบโฆษณาสองระบบอาจดูสมเหตุสมผลเมื่อมองแยกกัน แต่เมื่อรวมกันอาจก้าวร้าวมากขึ้นได้ Format สองแบบที่มี limit สี่นาทีแยกกันสามารถสลับกันจนผู้ใช้เจอ interruption ประมาณ 00:45, 02:45, 04:45 และ 06:45

จากจุดนี้ผมได้กฎที่ดีกว่า:

Frequency cap ควรถูกประเมินในระดับประสบการณ์ผู้ใช้ ไม่ใช่แยกตาม advertising script

ผู้ใช้สัมผัสผลรวมของ interruption ไม่ได้สนใจว่า config ไหนสร้างแต่ละอัน ดังนั้น production audit ควรถามว่าภายในช่วงเวลาหนึ่ง ผู้ใช้หนึ่งคนอาจพบ interruptive ad event ได้จริงกี่ครั้ง

จำนวน impression ดิบเป็น optimization target ที่ผิด

การสร้าง opportunity เพิ่มด้วยการลด cooldown เป็นเรื่องง่าย คำถามยากคือจะดึง monetization เพิ่มได้เท่าไรโดยไม่ลดมูลค่าทางเศรษฐกิจรวมของผู้ใช้

Configuration ที่มีโฆษณาต่อ visit น้อยกว่าอาจสร้าง revenue ระยะยาวมากกว่า หากรักษาการกลับมาใช้งานซ้ำได้ดีกว่า ดังนั้นผมสนใจ revenue per user over time มากกว่า impressions per visit อย่างหลัง maximize ได้ง่าย อย่างแรกคือปัญหาธุรกิจจริง

การทดลองที่แข็งแรงกว่าจะมองมากกว่ากราฟ aggregate กราฟเดียว

Observation จาก production เพียงพอให้ผมเห็นว่า catastrophic outcome ที่กลัวไม่ได้เกิดอย่างชัดเจน แต่มันยังไม่เพียงพอที่จะยืนยัน downstream effect ทั้งหมด

Experiment ที่แข็งแรงกว่าควรเปรียบเทียบ monetization revenue ต่อ unique user, revenue ต่อ visit, ad event ต่อ user, active engagement, interaction ที่มีความหมายใน product, returning-user rate, retention ตามเวลา และ long-term user value

ต้องวัดทั้งสองด้าน หากดูเฉพาะ advertising output เราแทบจะสรุปโดยอัตโนมัติว่าโฆษณามากกว่าดีกว่า หากดูเฉพาะ engagement ก็อาจพลาด revenue gain ที่มีความหมายแต่มี behavioral cost ต่ำมาก

ทำไมผมรักษา policy ให้เรียบง่าย

ผมไม่เห็นเหตุผลที่จะเพิ่ม exception มากขึ้นเรื่อย ๆ Final logic ยังอธิบายง่าย: รอ 45 วินาที อนุญาต monetization ที่ eligible interaction ถัดไป บังคับ hard cooldown สี่นาที แล้วค่อยให้ interaction ที่เหมาะสมถัดไป monetize ได้อีกครั้ง

Invariant ที่แข็งแรงเพียงไม่กี่ข้อเข้าใจ ทดสอบ และ debug ง่ายกว่า policy ที่มี exception ซับซ้อนจำนวนมาก

ความไม่สมมาตรของ policy ตั้งใจไว้

Policy ปฏิบัติต่อผู้ใช้ใหม่กับ engaged user ต่างกัน ผู้เข้าชมใหม่ได้รับการปกป้องมากกว่า ส่วนผู้ที่ใช้งานต่อจะสร้าง monetization opportunity เพิ่มขึ้นตามเวลา

แรงกดดันจากโฆษณาจึงเพิ่มตาม engagement ที่พิสูจน์แล้ว แทนที่จะเริ่มด้วยความเข้มสูงสุดทันที การเปลี่ยนแนวคิดนี้เป็นหนึ่งในผลลัพธ์ที่มีประโยชน์ที่สุดของการทดลอง

สิ่งที่ผมจะไม่สรุปจากกรณีนี้

ผมจะไม่บอกว่า 45 วินาทีถูกต้องสำหรับทุกที่ สี่นาทีคือ interval ที่เหมาะที่สุด popunder ที่ถี่ขึ้นไม่เคยทำร้าย engagement หรือค่าเฉลี่ยคงที่แปลว่าผู้ใช้ไม่โดนผลกระทบ และผมจะไม่ generalize workload ของ production หนึ่งระบบไปยังเว็บทุกประเภท

แต่ละผลิตภัณฑ์มีผู้ใช้ ความคาดหวัง acquisition source รูปแบบการใช้งาน และ economics ต่างกัน ผลลัพธ์นี้มีประโยชน์เพราะมันเฉพาะเจาะจง ไม่ใช่เพราะมันพิสูจน์กฎสากล

ส่วนที่เปลี่ยนความคิดของผม

ก่อนทดลอง ผมคิดว่าความสัมพันธ์ระหว่างแรงกดดันจากโฆษณากับ engagement เกือบเป็นกลไกตรงไปตรงมา: เพิ่มอย่างหนึ่งมากพอ อีกอย่างต้องลดลงให้เห็นชัด แต่พฤติกรรม production ไม่เรียบร้อยแบบนั้น

ผมเพิ่มความถี่ไปถึงระดับที่ถือว่าค่อนข้างสูง ผู้ใช้ยัง interact ต่อ และ aggregate engagement ยังอยู่ในช่วงรายวันที่คุ้นเคย นี่ไม่ได้แปลว่าต้นทุนเป็นศูนย์ แต่แปลว่ามันไม่ใหญ่พอที่จะสร้างสัญญาณชัดเจนอย่างที่คาดใน metric ที่ผมดูอยู่

ความต่างระหว่าง “ไม่มีผล” กับ “ไม่มีผลที่เห็นชัดในการวัดนี้” สำคัญมาก ระบบ production แทบไม่เคยให้ causal story ที่สะอาดอย่างที่เราต้องการ

กฎของผมตอนนี้

ผมไม่ถามแล้วว่าในทางเทคนิคสามารถแสดง popunder ถัดไปได้บ่อยแค่ไหน ผมถามว่าผู้ใช้ใหม่ควรได้ประสบการณ์ผลิตภัณฑ์แบบไม่ถูกรบกวนนานเท่าไรก่อน monetization เริ่ม ผู้ใช้ที่ engaged ควรได้ใช้งานต่อเนื่องนานเท่าไรก่อน event ใหม่จะเป็นไปได้ และโฆษณาเพิ่มนั้นเพิ่ม total user value จริงหรือเพียงเพิ่ม impression counter

สำหรับแอปนี้ ค่าที่ผมเก็บไว้คือ:

45 วินาทีก่อน eligibility ครั้งแรก
อย่างน้อย 4 นาทีระหว่าง event ที่สำเร็จ

ตัวเลขเหล่านี้เป็นเพียง implementation หนึ่งแบบ สิ่งที่ผมจะนำไปใช้ซ้ำคือกฎที่กว้างกว่า:

ปกป้องช่วงเริ่มต้นของ user journey, monetize engagement ที่พิสูจน์แล้วมากกว่าความสนใจแรกเริ่ม และวัดผลจากมูลค่าในระดับผู้ใช้ ไม่ใช่ปริมาณโฆษณาดิบ