เกิดอะไรขึ้นกับลิงก์แอปที่เปิดภายใน Instagram และ TikTok: วัดผลการเปลี่ยนเส้นทาง 74,000 ครั้ง

ตัวเลขเหล่านี้มาจากบันทึกการเปลี่ยนเส้นทางของบริการลิงก์อัจฉริยะ: URL เดียวที่ส่งโทรศัพท์ไปยัง App Store หรือ Google Play ทุกครั้งที่มีการเปิดลิงก์ภายในแอปโซเชียล เราจะส่งหน้าเล็ก ๆ ที่ส่งต่อผู้เข้าชมไปยังสโตร์ และหน้านั้นจะรายงานว่าเกิดอะไรขึ้นต่อ ด้านล่างคือสิ่งที่รายงานเหล่านั้นบอก วิธีที่เราวัด และจุดที่การวัดไปต่อไม่ได้

ข้อมูล

มีสองเรื่องที่เห็นชัดก่อนการวิเคราะห์ใด ๆ แอปของ Meta ส่งทราฟฟิกมามากกว่า TikTok หลายเท่า และบน Android การเข้าชมมากกว่าสามในสี่มาจากเบราว์เซอร์ในแอป ไม่ใช่ Chrome

หน้าเว็บรายงานสิ่งที่เกิดขึ้นอย่างไร

เมื่อมีการเปิดลิงก์ภายในเบราว์เซอร์ในแอป หน้าเว็บจะทำสามอย่างและส่ง beacon สำหรับแต่ละอย่าง:

• auto: เริ่มส่งต่อไปยังสโตร์ทันทีที่โหลด (iOS: location.replace ไปยัง URL ของ App Store; Android: URL แบบ intent:// ที่เปิดแอป Play Store แบบเนทีฟ)
• exit: หน้าเว็บถูกซ่อน (Page Visibility API) นี่คือสัญญาณที่ดีที่สุดที่หน้าเว็บมี ว่ามีบางอย่าง ซึ่งน่าจะเป็นสโตร์ ได้เข้ามาครองหน้าจอแล้ว
• stuck: หน้าเว็บยังมองเห็นอยู่ 2.2 วินาทีหลังการส่งต่อ จึงแสดงการ์ดสำรองที่มีปุ่มสโตร์ คำแนะนำ “เปิดในเบราว์เซอร์” และปุ่มคัดลอกลิงก์

หน้าเว็บมองไม่เห็น App Store หรือ Play Store ทุกอย่างด้านล่างจึงอนุมานจากสัญญาณทั้งสามนี้ และส่วนข้อจำกัดจะบอกว่าการอนุมานนั้นผิดพลาดตรงไหน

ข้อค้นพบที่ 1: ราว 1 ใน 11 ของการเข้าชม Android จาก Meta คือการโหลดล่วงหน้าที่ไม่มีใครเห็น

ตลอด 30 วันจนถึง 12 ตุลาคม มีกลุ่มเซสชัน Android กลุ่มหนึ่งที่มีพฤติกรรมแบบที่การเข้าชมของมนุษย์ทำไม่ได้: หน้าโหลดเสร็จ ตัวจับเวลาการส่งต่อไม่เคยทำงาน และหน้าถูกทำลาย 29 ถึง 31 วินาทีต่อมา ไม่มี auto ไม่มี stuck ไม่มีการแตะ บน iOS ไม่พบอะไรคล้ายกัน

นั่นคือลายเซ็นของเบราว์เซอร์ในแอป Instagram และ Facebook ที่โหลดลิงก์ในฟีดไว้ล่วงหน้า เก็บไว้แบบซ่อน แล้วทิ้งไปเมื่อผู้ใช้เลื่อนผ่าน หน้าเว็บได้รัน JavaScript ของเรา การเข้าชมจึงถูกบันทึก แต่ไม่เคยมีใครมองมันเลย

เราตรวจเกณฑ์นี้กับเซสชันที่เป็นมนุษย์อย่างชัดเจน: 0 จาก 17,606 เซสชันที่สโตร์เปิดขึ้น 2–3 s หลังการส่งต่อเข้าเกณฑ์ และ 0 จาก 244 เซสชันที่มีคนแตะปุ่มสโตร์เข้าเกณฑ์

สัดส่วนนี้เปลี่ยนไปในแต่ละสัปดาห์: 6.8% ในสัปดาห์สุดท้ายของช่วงนั้น และ 8.8%, 10.6% และ 10.0% ในสัปดาห์ก่อนหน้า มันยังกระจุกตัวในที่ที่มีแคมเปญ Instagram แบบเสียเงิน: 72% ของการโหลดล่วงหน้าในช่วงนั้นมาจากลิงก์เดียวที่อยู่เบื้องหลังแคมเปญ Instagram ขนาดใหญ่

ตั้งแต่ 16 ตุลาคม หน้าเว็บจัดประเภทนี้เองขณะทำงาน: มันรายงานการโหลดล่วงหน้าแทนการออก เมื่อถูกทำลายหลังผ่านไปอย่างน้อย 20 s โดยไม่เคยถูกแสดงเลย นี่คือสิ่งที่มันจับได้ตั้งแต่นั้น:

ตัวเลขที่นับขณะทำงานนี้เป็นค่าขั้นต่ำ การโหลดล่วงหน้าที่ถูกทำลายโดยไม่ได้รันสคริปต์ใด ๆ จะไม่ทิ้ง beacon ไว้ และกฎขณะทำงานเข้มงวดกว่าการสร้างข้อมูลย้อนหลัง

ทำไมจึงสำคัญ ถ้าคุณนับคลิกที่จุดเปลี่ยนเส้นทาง ราวหนึ่งใน 13 ของ “คลิก” จาก Instagram บน Android ไม่เคยถูกคนเห็นเลย อัตราจากคลิกสู่การติดตั้งของช่องทางนั้นจึงดูแย่กว่าความจริง และแดชบอร์ดแคมเปญที่สร้างจากจำนวนการเปลี่ยนเส้นทางดิบจะประเมินการเข้าถึงสูงเกินไปราว ๆ เท่านั้น

ข้อค้นพบที่ 2: TikTok ปฏิเสธ Play Store ขึ้นอยู่กับว่าใช้ webview ตัวไหน

ภายใน TikTok บน Android ผู้เข้าชมส่วนหนึ่งไม่เคยออกจากหน้าเลย: การส่งต่อทำงาน แต่ TikTok แสดงกล่องโต้ตอบของตัวเอง (“The action cannot be completed” — “ไม่สามารถดำเนินการได้”) มันไม่ได้เกิดกับทุกลิงก์ และหลายสัปดาห์ดูเหมือนว่าขึ้นอยู่กับลิงก์ แต่ไม่ใช่ มันขึ้นอยู่กับเบราว์เซอร์ในแอปที่ TikTok ใช้กับผู้เข้าชมคนนั้น ซึ่ง user-agent เปิดเผยออกมา:

เซสชันจะนับว่าผ่านเมื่อการส่งต่อทำงานและหน้าถูกซ่อน และนับว่าไม่ผ่านเมื่อการ์ดสำรองถูกแสดง อัตราคือ ผ่าน / (ผ่าน + ไม่ผ่าน) ต่ออุปกรณ์และต่อวัน:

การเปรียบเทียบที่ชี้ขาดคือการตรึงลิงก์และวันให้คงที่ เพราะสัดส่วนของรูปแบบเปลี่ยนไปทุกสัปดาห์:

ลิงก์เดียวกัน โค้ดเปลี่ยนเส้นทางเดียวกัน วันเดียวกัน: webview หนึ่งยอมให้สโตร์เปิด อีกตัวแทบไม่ยอม โดเมนที่กำหนดเองไม่ได้สร้างความแตกต่างในข้อมูล 90 วัน TikTok ไม่มีเอกสารเกี่ยวกับกล่องโต้ตอบนี้ สิ่งที่ทำให้มันเกิด หรือผู้ใช้คนไหนได้ webview ตัวไหน การแยกตาม user-agent จึงเป็นทั้งหมดที่มี

ทำไมจึงสำคัญ ไม่มีรูปแบบ URL ใดแก้ปัญหานี้ได้: การหลุดออกด้วย intent:// และ URL https://play.google.com ธรรมดาถูกปฏิเสธเหมือนกัน สิ่งที่ทำได้คืออย่าซ่อนทางออก: ภายใน TikTok ให้แสดงคำแนะนำ “เปิดในเบราว์เซอร์” และปุ่มคัดลอกทันที แทนที่จะรอให้หมดเวลา

ข้อค้นพบที่ 3: บน iOS App Store เปิดซ้อนทับเบราว์เซอร์ในแอป

บน Android หลังการส่งต่อ หน้าเว็บจะถูกซ่อนในเซสชันส่วนใหญ่ โดยทั่วไป 1 ถึง 3 วินาทีต่อมา บน iOS ภายใน Instagram และ Facebook มักไม่เป็นเช่นนั้น แม้การส่งต่อจะทำงานในแทบทุกเซสชัน:

ถ้าผู้เข้าชม iOS สองในสามติดอยู่หน้าการ์ดสำรองที่มองเห็นได้พร้อมปุ่ม “เปิด App Store” จริง ก็น่าจะมีคนแตะมันไม่น้อย แต่ไม่ใช่: มีเพียง 0.9% ของการโหลดหน้า Instagram บน iOS และ 0.4% ของการโหลด Facebook บน iOS ที่แตะปุ่ม และไม่มี iOS เวอร์ชันไหนที่มัน “ใช้ได้”:

คำอธิบายที่เข้ากับข้อมูลคือ ภายใน Instagram และ Facebook บน iOS นั้น App Store ขึ้นมาซ้อนทับเบราว์เซอร์ในแอปโดยไม่ส่งมันไปทำงานเบื้องหลัง หน้าเว็บจึง “มองเห็น” อยู่ตลอด ทำให้ visibilitychange และ pagehide ไม่เคยทำงาน แม้ผู้เข้าชมกำลังดู App Store อยู่

ทำไมจึงสำคัญ ตัวชี้วัดใดก็ตามที่อนุมานการเปิดสโตร์จากการที่หน้าเว็บหายไปจากหน้าจอ ล้วนผิดบน iOS เราเคยแสดงเปอร์เซ็นต์ “การเข้าถึงสโตร์” ที่คำนวณแบบนั้นให้ลูกค้าดู และมันบอกลูกค้าที่จ่ายเงิน 10 จาก 12 รายว่าลิงก์ที่ใช้งานได้นั้นเสีย เราจึงเอามันออก บน iOS สัญญาณการติดตั้งที่เชื่อถือได้อยู่ฝั่งสโตร์: รายงานแคมเปญของ App Store Connect โดยใส่ provider token (pt) และ campaign token (ct) ไว้ใน URL ของ App Store

เรื่องย่อย ๆ ที่เราวัดได้ระหว่างทาง

• Play Store แสดงผลช้าบน Android ในเซสชัน Instagram บน Android ที่การส่งต่อทำงาน หน้าถูกซ่อน 0–1 s หลังการเข้าชมใน 1,061 เซสชัน 2–3 s ใน 2,596 เซสชัน และ 4–8 s ใน 1,273 เซสชัน (7 วัน) ตัวจับเวลา “สำเร็จไหม?” แบบ 2 วินาทีจะทำงานก่อนสโตร์ปรากฏในความสำเร็จจริงจำนวนมาก funnel ของเราเองเคยนับกรณีเหล่านั้นเป็นความล้มเหลว จนเรายอมให้การออกที่ช้าได้ถึง 8 s หลังการส่งต่อยังนับอยู่
• อัตราความล้มเหลวจริงนั้นต่ำ ใน 7,357 เซสชัน Instagram บน Android ที่สร้างขึ้นใหม่ตลอด 3 วันช่วงต้นเดือนตุลาคม รูปแบบ “ส่งต่อแล้วไม่มีอะไรเกิดขึ้น” คิดเป็น 1.9% ของเซสชัน และ 24.3% ของผู้เข้าชมเหล่านั้นแตะลิงก์ซ้ำภายใน 3 นาที ผู้เข้าชมที่เซสชันแสดงการ์ดสำรองแตะซ้ำที่ 5.4% ใกล้เคียงกับผู้ที่สโตร์เปิดแล้ว (4.6%): “ความล้มเหลว” ส่วนใหญ่จึงไม่ใช่ความล้มเหลว
• การบังคับให้แตะทำให้เสียทราฟฟิกส่วนใหญ่ ก่อนที่หน้าเว็บจะเริ่มส่งต่อตั้งแต่ตอนโหลด มันแสดงการ์ดที่มีปุ่มสโตร์ ตลอด 30 วัน การเข้าชมในแอป 10,523 ครั้งเกิดการแตะ 2,119 ครั้ง: ผู้เข้าชมราว 80% ไม่เคยไปถึงสโตร์

วิธีการ

• แหล่งข้อมูล การเข้าชมลิงก์อัจฉริยะทุกครั้งและ beacon ทุกตัวจากหน้าส่งต่อจะถูกเขียนลง Cloudflare Workers Analytics Engine พร้อมแพลตฟอร์ม เบราว์เซอร์ในแอป (จาก user-agent) ประเภทเหตุการณ์ และเวลาที่ละเอียดถึงวินาที ผู้เข้าชมที่ user-agent ประกาศตัวว่าเป็นบอต crawler หรือตัวดึงตัวอย่างลิงก์จะถูกแยกไว้และไม่นับในตัวเลขใด ๆ ที่นี่
• เซสชัน Analytics Engine ไม่มี id ของการโหลดหน้า เซสชันจึงถูกสร้างใหม่โดยจับคู่การเข้าชมกับ beacon ที่มีลิงก์ ประเทศ เมือง user-agent และเบราว์เซอร์ในแอปเดียวกันภายในหนึ่งชั่วโมงถัดไป จนถึงการเข้าชมครั้งถัดไปที่มีคีย์เดียวกัน beacon ราว 98% จับคู่กับการเข้าชมได้
• การโหลดล่วงหน้า (ข้อค้นพบที่ 1) เกณฑ์ย้อนหลัง: ไม่มีการส่งต่อ ไม่มีการ์ดสำรอง ไม่มีการแตะ และมีการออก 20 s ถึง 15 นาทีหลังการเข้าชม เกณฑ์ขณะทำงานตั้งแต่ 2026-10-16: หน้าเว็บรายงานการโหลดล่วงหน้าเมื่อถูกทำลายหลังอย่างน้อย 20 s โดยไม่เคยถูกแสดงและตัวจับเวลาการส่งต่อไม่เคยทำงาน (หรือโหลดแบบซ่อน) beacon มีโทเค็นที่ลงลายเซ็นและใช้ได้ครั้งเดียว จึงส่งซ้ำเพื่อลบการเข้าชมจริงไม่ได้
• TikTok (ข้อค้นพบที่ 2) เซสชันระบุด้วยลิงก์ รุ่นอุปกรณ์ เวอร์ชันแอป TikTok และวัน กฎรูปแบบ: เวอร์ชัน musical_ly_ ที่มีจุด → A; ไม่เช่นนั้น มี JsSdk → B; นอกนั้น C ผู้เข้าชมจากเครือข่ายโฮสติ้งถูกนับแยกและไม่รวมในตาราง การวัดซ้ำ 30 วันใช้สคริปต์เดียวกับการวิเคราะห์ 90 วันครั้งแรก
• ยอดรวม ใช้ sample interval ของ Analytics Engine (2–4% ของแถวแทนเหตุการณ์มากกว่าหนึ่งครั้ง) ตารางระดับเซสชันนับเป็นแถว

ข้อจำกัด

• เราไม่เคยเห็นสโตร์ “ถูกซ่อน” เป็นตัวแทนของ “สโตร์เปิดแล้ว” มันยังเกิดขึ้นเมื่อผู้เข้าชมสลับแอปหรือล็อกโทรศัพท์ด้วย
• เวลาละเอียดถึงระดับวินาที และเซสชันเป็นการสร้างขึ้นใหม่ การโหลดเร็ว ๆ สองครั้งจากอุปกรณ์เดียวกันอาจถูกรวมกัน
• การกระจุกตัว ลิงก์ใหญ่ไม่กี่ลิงก์ครองบางช่วงเวลา: แคมเปญ Instagram หนึ่งคิดเป็น 72% ของการโหลดล่วงหน้าใน 30 วัน และลิงก์สองลิงก์มีเซสชัน TikTok เป็นส่วนใหญ่ ตารางลิงก์เดียวกันมีไว้ด้วยเหตุผลนี้
• ไม่มีสิ่งใดที่นี่ได้ทดสอบบนโทรศัพท์จริง พฤติกรรมทั้งหมดอนุมานจากสิ่งที่หน้าเว็บรายงาน คำอธิบายเรื่อง iOS ในข้อค้นพบที่ 3 คือคำอธิบายที่เข้ากับข้อมูล ไม่ใช่สิ่งที่เราเห็นกับตา
• ทราฟฟิกนี้เป็นของเรา นี่คือผู้เข้าชมของแอปที่ใช้ลิงก์ของเรา ซึ่งเอนไปทางแคมเปญ Instagram และ Facebook ในไม่กี่ประเทศ ส่วนผสมอื่นจะให้เปอร์เซ็นต์ต่างออกไป แม้กลไกน่าจะเหมือนเดิม
• การโหลดล่วงหน้าที่ไม่เคยรัน JavaScript นั้นมองไม่เห็น 12% ของการโหลดหน้า Instagram บน Android ไม่ส่ง beacon เลย และบางส่วนน่าจะเป็นการโหลดล่วงหน้าเช่นกัน

ควรทำอย่างไร

1. เริ่มส่งต่อตั้งแต่ตอนโหลด หน้าที่รอให้แตะจะเสียผู้เข้าชมในแอปส่วนใหญ่ เก็บปุ่มแบบแมนนวลไว้เป็นทางสำรอง แสดงเฉพาะเมื่อการส่งต่อล้มเหลวอย่างเห็นได้ชัด
2. บน Android ใช้ `intent://` คู่กับ `S.browser_fallback_url` URL https://play.google.com ภายใน webview จะเปิดเว็บไซต์ Play Store ซึ่งติดตั้งอะไรไม่ได้หากไม่ล็อกอิน
3. ให้เวลาสโตร์ที่ช้า รออย่างน้อย 3 s ก่อนสรุปว่าการส่งต่อล้มเหลว และยังนับการออกที่มาช้า
4. ภายใน TikTok ให้แสดงทางออกทันที: “··· → เปิดในเบราว์เซอร์” และปุ่มคัดลอกลิงก์ ไม่มีการเปลี่ยน URL ใดทำให้การปฏิเสธของ TikTok หายไป
5. อย่านับการโหลดล่วงหน้าของ Meta เป็นคลิก ถ้าคุณรายงานคลิกจากการเปลี่ยนเส้นทาง ให้คาดว่า 2–9% ของการเข้าชม Instagram และ Facebook บน Android เป็นหน้าที่ไม่มีใครเห็น
6. วัดการติดตั้งที่สโตร์ ด้วยลิงก์แคมเปญ App Store Connect (pt + ct) บน iOS และ Play Install Referrer บน Android ไม่ใช่ด้วยเหตุการณ์ของหน้าเว็บ

เราสร้าง onestore.link ซึ่งทำทั้งหกข้อนี้เป็นค่าเริ่มต้นให้ทุกลิงก์ และข้อมูลข้างต้นมาจากบันทึกการเปลี่ยนเส้นทางของมัน

คำถามและคำตอบ