Biến truy vấn tìm kiếm thành một bản tóm tắt trang
Bắt đầu với một cụm ý định chặt chẽ. Ghi lại chủ đề truy vấn, lời hứa quảng cáo, câu hỏi khả dĩ, URL đích và một hành động chính. Một truy vấn thợ sửa ống nước khẩn cấp cần khu vực phục vụ, thời gian sẵn có, phương thức liên hệ và bằng cấp; một truy vấn danh mục sản phẩm có thể cần giá, việc phù hợp và chi tiết so sánh.
Khớp thông điệp (message match) giữ nguyên ý nghĩa; không phải lặp từ khóa. Phần nhìn thấy đầu (hero) nên trả lời đây là gì và lý do khách click với cùng một ưu đãi hoặc kết quả như quảng cáo. Đặt loại trừ, cơ sở tính giá, điều kiện đủ điều kiện hoặc giới hạn địa lý cạnh một khẳng định khi chúng ảnh hưởng đến quyết định.
Viết chủ đề truy vấn, ưu đãi, đối tượng, hành động và bằng chứng cần có trước khi thiết kế.
Cách diễn đạt chính xác không thể sửa một ưu đãi mà doanh nghiệp không thể cung cấp.
Làm cho màn hình đầu tiên đáng để thực hiện hành động tiếp theo
Sử dụng tiêu đề rõ ràng, giải thích ngắn gọn, hành động hiển thị và bằng chứng cần thiết để làm cho hành động đó có độ tin cậy: giá chính xác, thông số kỹ thuật, chi tiết giao hàng, quy tắc đủ điều kiện, chính sách hoàn trả hoặc phản hồi có nguồn gốc. Liên kết đến chi tiết đầy đủ thay vì che giấu các điều kiện vật chất.
Một hành động nổi bật phải khớp với ý định: “Nhận báo giá,” “Kiểm tra tồn kho,” và “Mua ngay” là những cam kết khác nhau. Nếu cần thông tin trước, hãy làm cho việc tiếp cận dễ dàng. Tránh pop-up, tự động tải xuống và điều hướng không liên quan làm gián đoạn nhiệm vụ; Google cấm các đích đến khó hoặc gây phiền toái không cần thiết.
Đặt giá trị, hành động và điều kiện then chốt gần đầu; hỗ trợ chúng bên dưới.
Dùng thông tin doanh nghiệp cụ thể, có thể xác minh thay vì các khẳng định chung chung.
Thiết kế biểu mẫu trên di động để hoàn thành
Kiểm tra luồng trên điện thoại: view trang đích, chấp thuận (consent), biểu mẫu, kiểm tra hợp lệ (validation), xác nhận, liên kết gọi điện và chuyển giao. Ở khung nhìn hẹp, văn bản và điều khiển không được cắt hoặc chồng chéo. WCAG 2.2 nói rằng nội dung dọc thông thường nên tái luồng mà không mất thông tin hoặc chức năng ở 320 CSS pixel, trừ khi bố cục hai chiều là thiết yếu.
Cho mỗi ô nhập một nhãn hiển thị và liên kết, và nói rõ các định dạng không hiển nhiên. W3C giải thích rằng nhãn và hướng dẫn cho biết người dùng cần dữ liệu gì và có thể ngăn lỗi. Đừng dựa vào gợi ý tạm thời trong ô, màu sắc hoặc chỉ biểu tượng. Thử thứ tự bàn phím, focus, xử lý lỗi, phóng to và đánh giá bằng công nghệ hỗ trợ phù hợp với trang.
Sử dụng điều khiển có kích thước thoải mái khi có thể. Mục tiêu 44 x 44 CSS-pixel của WCAG là tiêu chí nâng cao Level AAA, không phải quy tắc pháp lý phổ quát.
Chỉ hỏi dữ liệu cần cho bước tiếp theo đã nêu.
Dự toán cho tốc độ và bảo vệ đường dẫn
Dùng chẩn đoán lab trước khi phát hành và dữ liệu hiện trường sau phát hành. Web Vitals định nghĩa LCP là tải cảm nhận, INP là khả năng phản hồi và CLS là ổn định trực quan. Ngưỡng khuyến nghị cho trải nghiệm tốt là LCP trong vòng 2.5 giây, INP ở 200 mili giây hoặc nhỏ hơn, và CLS ở 0.1 hoặc nhỏ hơn tại phân vị 75, tách theo di động và desktop. Chúng là chuẩn mực, không phải đảm bảo chuyển đổi.
Ưu tiên màn hình đầu: đặt kích thước ảnh, cung cấp ảnh có kích thước phù hợp, hoãn mã không cần thiết, và điều tra phản hồi chậm, tài nguyên chặn render, tác vụ dài, và dịch chuyển bố cục. Thực thi URL cuối, chuyển hướng, tham số chiến dịch, consent, submit, xác nhận và các phụ thuộc quan trọng. Trang ít lưu lượng có thể thiếu dữ liệu trường; dùng kiểm tra lab và thu thập dữ liệu người dùng thật khi lưu lượng tăng.
Thực thi trang, hành động và xác nhận trên các điều kiện di động và desktop đại diện trước khi công bố.
Dùng các thực hành tiền kiểm và khắc phục của SIU để giảm các suy giảm đường dẫn trang đích có thể tránh được trước khi chiến dịch mở rộng.
Giữ phạm vi tin cậy, thu thập dữ liệu và thanh toán
Cho danh tính doanh nghiệp, điều kiện ưu đãi, lựa chọn quyền riêng tư và đường liên hệ nhất quán với quảng cáo và hiển thị trước các hành động nhạy cảm. Chỉ thu thập dữ liệu cần cho mục đích đã nêu. Việc xác thực, chấp thuận và lưu giữ là quyết định của sản phẩm và pháp lý; bài viết này mang tính giáo dục, không phải tư vấn pháp luật.
Nếu đường dẫn nhận thẻ hoặc nhúng khung thanh toán, thay đổi script và header HTTP có thể ảnh hưởng đến bảo mật trang thanh toán. PCI SSC nói rằng các yêu cầu PCI DSS v4.x 6.4.3 và 11.6.1 đề cập tới ủy quyền và toàn vẹn script cùng giám sát can thiệp (tamper monitoring), bao gồm các header có tác động đến bảo mật. Dùng kiến trúc thanh toán được phê duyệt và có người đánh giá an ninh, tuân thủ và pháp lý có trình độ thẩm định triển khai và nghĩa vụ nhà thu mối (acquirer).
Liệt kê script, chủ sở hữu, mục đích và các trang trước khi thay đổi đường dẫn thanh toán.
Không suy diễn sự tuân thủ PCI DSS từ danh sách kiểm này; PCI SSC không xác định việc tuân thủ của một thực thể.
Thử nghiệm mà không làm rối kết quả
Đặt một giả thuyết, một kết quả chính và các giới hạn như lỗi trang, lead không hợp lệ, tốc độ và hủy đơn. Giữ chủ đề truy vấn, điều khoản ưu đãi, nguồn lưu lượng, định nghĩa đo lường và thay đổi trang đủ ổn định để diễn giải so sánh.
Google Ads định nghĩa thử nghiệm chiến dịch là một bản nháp được kiểm tra đối chiếu với bản gốc bằng cách dùng một phần lưu lượng và ngân sách trong một khoảng thời gian xác định. Điều đó không tự động xác thực mọi thử nghiệm URL trang đích. Dùng phương pháp so sánh công bằng các biến thể, ghi lại phơi nhiễm và ngày, và quay lại biến thể gây hại cho giới hạn.
Đừng thay đổi tiêu đề, ưu đãi, độ dài biểu mẫu và đối tượng cùng lúc khi bạn cần biết yếu tố nào gây ra kết quả.
Lưu giả thuyết, biến thể, quy tắc, chỉ số, giới hạn, kết quả, chủ sở hữu và quyết định khôi phục.