หน้า Landing Page บนมือถือสำหรับ Native Ads: กฎการออกแบบที่ช่วยเพิ่ม Conversion

Traffic จาก Native Ads ส่วนใหญ่มาจากมือถือ เนื่องจากมาจากฟีดเนื้อหาที่ผู้คนเลื่อนดูบนโทรศัพท์ ดังนั้น pre-lander ที่ออกแบบสำหรับเดสก์ท็อปก่อนแล้วค่อยปรับลงมาจะทำผลงานได้แย่กว่าหน้าที่ออกแบบสำหรับมือถือเป็นหลักตั้งแต่แรก กฎการออกแบบที่สำคัญที่สุดคือ น้ำหนักหน้าเว็บ, ตำแหน่ง CTA ที่นิ้วโป้งเอื้อมถึง, เลย์เอาต์คอลัมน์เดียว และการหลีกเลี่ยงสิ่งใดๆ ที่ทีมตรวจสอบการปฏิบัติตามกฎของเครือข่ายถือว่าเป็น interstitial หรือ forced interaction

เหตุใดแนวทางออกแบบสำหรับเดสก์ท็อปก่อนแล้วค่อยปรับจึงล้มเหลวบ่อยครั้ง#

ทีมที่ออกแบบ pre-lander บนหน้าจอเดสก์ท็อปก่อนมักจะฝังสมมติฐานที่ไม่สามารถใช้งานได้เมื่อย่อลงมาเป็นโทรศัพท์: เลย์เอาต์หลายคอลัมน์ที่ถูกบีบให้เหลือคอลัมน์เดียวจนอ่านไม่ได้ในนาทีสุดท้าย, ภาพ hero ที่ครอบตัดสำหรับอัตราส่วนกว้างแต่สูญเสียจุดโฟกัสเมื่อต้องครอบตัดอีกครั้งสำหรับอัตราส่วนแคบ, และตำแหน่ง CTA ที่ตัดสินจากความสมดุลบนหน้าจอใหญ่แทนที่จะเป็นตำแหน่งที่นิ้วโป้งเอื้อมถึงได้จริง สิ่งเหล่านี้ไม่ปรากฏเป็น "บั๊ก" ที่คุณจะพบในการรีวิวบนเดสก์ท็อปอย่างรวดเร็ว แต่จะปรากฏเมื่อคุณดูหน้าเว็บในแบบที่ผู้เข้าชมจริงของคุณจะเห็น นั่นคือเหตุผลที่การออกแบบสำหรับมือถือเป็นหลักตั้งแต่ร่างแรก แล้วค่อยปรับขึ้นไปหาเดสก์ท็อป (หากจำเป็น) สร้างความประหลาดใจน้อยกว่าการทำในทางกลับกัน

ออกแบบสำหรับนิ้วโป้ง ไม่ใช่สำหรับเมาส์#

ทุกองค์ประกอบที่ต้องการการแตะที่แม่นยำจะทำให้ conversion บนโทรศัพท์ลดลง ปุ่ม CTA ต้องมีขนาดใหญ่พอที่จะกดได้อย่างแม่นยำ วางตำแหน่งที่นิ้วโป้งพักได้ตามธรรมชาติ (ส่วนกลางล่างถึงหนึ่งในสามล่างของหน้าจอทำงานได้ดีกว่าปุ่มที่ต้องยืดนิ้วไปถึงด้านบน) และเว้นระยะห่างจากองค์ประกอบอื่นที่สามารถแตะได้ เพื่อไม่ให้การแตะพลาดส่งผู้ใช้ไปยังที่ที่คุณไม่ได้ตั้งใจ แถบ CTA แบบ sticky ที่มองเห็นได้ขณะที่ผู้อ่านเลื่อนผ่านบทความโฆษณาที่ยาว ช่วยลดความจำเป็นในการเลื่อนกลับขึ้นไปเมื่อพวกเขาตัดสินใจแล้ว ซึ่งสำคัญมากขึ้นเมื่อหน้าเว็บของคุณยาวขึ้นและรูปแบบของคุณโน้มเอียงไปทางเรื่องราวเต็มรูปแบบมากกว่าหน้าเว็บเชื่อมต่อสั้นๆ

น้ำหนักหน้าเว็บคือคันโยก conversion ไม่ใช่แค่เรื่องทางเทคนิค#

ทุกวินาทีที่เพิ่มขึ้นของเวลาโหลดบนการเชื่อมต่อมือถือคือโอกาสที่จะสูญเสียผู้ที่คลิกด้วยแรงกระตุ้นจากฟีดเนื้อหาและไม่มีใจรอหน้าเว็บที่โหลดช้า บีบอัดภาพ hero อย่างรุนแรง หลีกเลี่ยงวิดีโอที่เล่นอัตโนมัติ (ซึ่งมักจะถูกตรวจสอบการปฏิบัติตามกฎในหลายเครือข่ายและเผาผลาญข้อมูลมือถือที่ผู้อ่านไม่ได้ยินยอมใช้), lazy load ทุกสิ่งที่อยู่ต่ำกว่า fold และทำให้ DOM เรียบง่าย สิ่งนี้รวมกับตัวเลือกโดเมนและโฮสติ้ง; หน้าเว็บที่โฮสต์อยู่หลังเซิร์ฟเวอร์แชร์ที่ช้าและใช้งานเกินพิกัด หรือที่ต้องผ่านการ redirect ที่ไม่จำเป็น เพิกถอนงานออกแบบที่ดีก่อนที่พิกเซลเดียวจะแสดงผล โฮสติ้งที่ดีเป็นข้อกำหนดเบื้องต้นสำหรับการออกแบบมือถือที่ดี ไม่ใช่เรื่องแยกต่างหากที่คุณจะมาแก้ไขในภายหลัง

เลย์เอาต์: คอลัมน์เดียว, การไหลแนวตั้ง, ไม่มีสิ่งประหลาดด้านข้าง#

เลย์เอาต์หลายคอลัมน์ที่ใช้งานได้บนเดสก์ท็อปมักจะพังทลายบนมือถือ เว้นแต่ว่าจะถูกออกแบบสำหรับมือถือเป็นหลัก ใช้คอลัมน์แนวตั้งเดียว: บล็อกภาพ hero หรือหัวข้อ, เนื้อหาสนับสนุนในย่อหน้าสั้นๆ, การแบ่งส่วนที่ชัดเจนก่อน CTA, จากนั้นจึงเป็นการเปลี่ยนไปสู่ข้อเสนอหรือบล็อกเนื้อหาถัดไป หลีกเลี่ยงการเลื่อนแนวนอนทั้งหมด มันทำให้สับสนบนโทรศัพท์และแทบจะไม่เกิดขึ้นโดยตั้งใจ

สิ่งที่ควรหลีกเลี่ยงเพราะเครือข่ายจะปฏิเสธ#

• Forced interstitial หรือป๊อปอัพที่บล็อกเนื้อหาก่อนการกระทำที่แท้จริงของผู้ใช้ นโยบายบรรณาธิการของเครือข่าย Native Ads ส่วนใหญ่ถือว่าสิ่งเหล่านี้เป็นประสบการณ์ผู้ใช้ที่แย่และเป็นสาเหตุทั่วไปที่ทำให้ครีเอทีฟถูกปฏิเสธ; ตรวจสอบเอกสารปัจจุบันของเครือข่ายนั้นๆ ก่อนพึ่งพารูปแบบ interstitial ใดๆ
• เสียงหรือวิดีโอที่เล่นอัตโนมัติ เหตุผลเดียวกัน: มันทำให้ผู้อ่านประหลาดใจ, เผาผลาญข้อมูลของพวกเขา, และดึงความสนใจในการตรวจสอบ
• องค์ประกอบ UI ระบบปลอม (คำเตือน "แบตเตอรี่ต่ำ" ปลอม, แบนเนอร์แจ้งเตือนปลอม, ปุ่มปิดปลอมที่ไม่ได้ปิดอะไรเลย) สิ่งเหล่านี้เข้าใกล้พื้นที่ cloaking ในมุมมองของทีมตรวจสอบการปฏิบัติตามกฎ แม้ว่าจะไม่มีการ cloaking ทางเทคนิคเกิดขึ้น เพราะพวกเขาหลอกลวงผู้อ่านเกี่ยวกับสิ่งที่พวกเขากำลังดูอยู่
• การเปิดเผยข้อมูลที่ถูกฝังหรือซ่อนอยู่หลังการแตะ การเปิดเผยข้อมูลการสนับสนุนและการโฆษณาต้องมองเห็นได้โดยไม่ต้องมีปฏิสัมพันธ์เพิ่มเติมจากผู้อ่าน; ดู FTC Disclosure Rules for Advertorials & Native Ads สำหรับความหมายของ "มองเห็นได้" ภายใต้แนวทางปัจจุบัน

การจัดเรียงตัวอักษรและจังหวะการอ่านบนหน้าจอเล็ก#

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

เป้าหมายการสัมผัสนอกเหนือจากแค่ CTA#

CTA หลักได้รับความสนใจในการออกแบบ แต่องค์ประกอบที่สามารถแตะได้รอง (ลิงก์ "เรียนรู้เพิ่มเติม", ปุ่มปิดบนองค์ประกอบใดๆ ที่สามารถปิดได้, การนำทางหากหน้ามี) ต้องการขนาดและระยะห่างที่เหมาะกับนิ้วโป้งเช่นเดียวกัน ปุ่มปิดที่มีอยู่ทางเทคนิคแต่เล็กเกินไปที่จะกดได้อย่างแม่นยำ ในทางปฏิบัติแล้วทำหน้าที่เหมือนไม่มีปุ่มปิดเลย และถูกตีความว่าเป็นสิ่งที่น่าหงุดหงิดหรือหลอกลวงสำหรับผู้อ่านที่พยายามจะปิดบางสิ่ง แนวทางการออกแบบมือถือของ Apple และ Google เองต่างก็ระบุขนาดเป้าหมายการสัมผัสขั้นต่ำด้วยเหตุผลนี้โดยเฉพาะ และการปฏิบัติตามเป็นพื้นฐานที่สมเหตุสมผลแม้จะอยู่นอกแอปพลิเคชันแพลตฟอร์มเนทีฟ

ฟอร์ม: ช่องข้อมูลน้อยลง, ใช้ input type แบบเนทีฟ#

หาก pre-lander หรือขั้นตอนข้อเสนอที่อยู่เบื้องหลังมันรวบรวมข้อมูลใดๆ ทุกช่องข้อมูลเพิ่มเติมคือจุดที่ทำให้ผู้ใช้หลุดออกจากหน้าเว็บบนมือถือ ซึ่งการพิมพ์ช้ากว่าและมีโอกาสผิดพลาดสูงกว่าบนเดสก์ท็อป ใช้ input type ที่ถูกต้องสำหรับแต่ละช่อง (แป้นตัวเลขสำหรับหมายเลขโทรศัพท์, แป้นอีเมลสำหรับช่องอีเมล) เพื่อให้แป้นพิมพ์ของโทรศัพท์เองช่วยผู้เข้าชมแทนที่จะบังคับให้พวกเขาล่าตัวอักษรบนแป้นพิมพ์ทั่วไป หากคุณสามารถเลื่อนการกรอกช่องข้อมูลไปยังขั้นตอนถัดไปใน funnel แทนที่จะขอใน pre-lander เอง ให้ทำเช่นนั้น

รายละเอียดทางภูมิศาสตร์และภาษาที่ทำให้หน้าเว็บมือถือมีปัญหาโดยเฉพาะ#

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

การจัดการ UI ที่เครือข่ายฉีดเข้ามาบนหน้าเว็บของคุณ#

เครือข่าย Native Ads หลายแห่งแสดงองค์ประกอบของตัวเองรอบๆ หรือบนเนื้อหาของคุณ เช่น ป้ายกำกับ "สนับสนุน", ตัวควบคุมปิดหรือกลับ, บางครั้งวิดีเจ็ตความคิดเห็นหรือการมีส่วนร่วมสไตล์เนทีฟที่เครือข่ายควบคุมเอง ออกแบบหน้าเว็บของคุณโดยสมมติว่ามี overlay นั้นอยู่ แทนที่จะทดสอบเฉพาะในสภาพแวดล้อมพรีวิวที่สะอาด เนื่องจาก CTA หรือหัวข้อที่วางตำแหน่งตรงที่องค์ประกอบ UI ของเครือข่ายเองแสดงผลบนอุปกรณ์จริง จะมองไม่เห็นโดยผู้อ่านอย่างมีประสิทธิภาพ ตรวจสอบว่าหน้าเว็บของคุณดูเป็นอย่างไรจริงๆ ภายในการแสดงผลในฟีดจริงของเครือข่าย ไม่ใช่แค่เป็น URL แบบสแตนด์อโลน ก่อนตัดสินใจเลย์เอาต์สุดท้ายที่ขึ้นอยู่กับการวางตำแหน่งแนวตั้งที่แม่นยำใกล้ด้านบนของหน้า

การตรวจสอบสิ่งที่ใช้งานได้อยู่แล้วบนเครือข่ายที่เน้นมือถือ#

ในทางปฏิบัติ เครือข่ายบางแห่งมีสัดส่วนผู้ใช้มือถือมากกว่าเครือข่ายอื่น และรูปแบบ pre-lander ที่ชนะก็แตกต่างกันไปตามนั้น การรีวิวครีเอทีฟที่กำลังทำงานอยู่และ lander ที่ติดตามได้บน OpenAdLibrary's native ad spy tool แสดงให้คุณเห็นว่าตัวเลือกรูปแบบและเลย์เอาต์ใดที่ยังคงอยู่บนเครือข่ายที่กำหนดในขณะนี้ แทนที่จะใช้คำแนะนำ UX มือถือทั่วไปที่ไม่คำนึงถึงพฤติกรรมของผู้ชมของเครือข่ายเฉพาะ MSN Native Ads: The Advertiser's Guide และ How Taboola Ads Work ต่างครอบคลุมการจัดวางเฉพาะเครือข่ายและพฤติกรรมผู้ชมที่ส่งผลต่อการตัดสินใจเลย์เอาต์เหล่านี้

การเข้าถึงใช้งานซ้อนทับกับ conversion มากกว่าที่คนคิด#

ความคมชัดของสีระหว่างข้อความและพื้นหลังที่เพียงพอ, ขนาดฟอนต์ที่อ่านได้โดยไม่ต้องซูม, และปุ่ม CTA ที่สามารถแยกแยะได้ด้วยมากกว่าแค่สีเดียว ช่วยผู้เข้าชมที่มีปัญหาด้านการมองเห็น แต่ก็ช่วยผู้เข้าชมทุกคนที่อ่านหน้าจอโทรศัพท์กลางแจ้งในแสงแดดจ้าหรือบนจอแสดงผลที่เก่าและมืดกว่า จัดการปฏิบัติการเข้าถึงใช้งานพื้นฐานเป็นปัจจัยนำเข้า conversion ไม่ใช่ช่องทำเครื่องหมายการปฏิบัติตามกฎแยกต่างหาก เนื่องจากประชากรที่มันช่วยนั้นมีขนาดใหญ่กว่าประชากรที่มันมุ่งหมายอย่างเป็นทางการ

การทดสอบที่สำคัญจริงๆ#

ก่อนใช้งานการออกแบบ mobile pre-lander ใดๆ ให้โหลดมันบนโทรศัพท์จริงผ่านการเชื่อมต่อที่จำกัดความเร็ว ไม่ใช่แค่ใน mobile emulator ของเบราว์เซอร์บนเดสก์ท็อป Emulator แสดง viewport ได้ถูกต้อง แต่แทบจะไม่สามารถจำลองเวลาโหลดจริง, ความแม่นยำของการแตะเป้าหมาย, หรือพฤติกรรมขององค์ประกอบ sticky ภายใต้การเลื่อนจริงได้ ห้านาทีบนอุปกรณ์จริงจะพบปัญหาที่การทำซ้ำบนเดสก์ท็อปเป็นเวลาหลายสัปดาห์จะพลาดไปทั้งหมด