clickSomo
Mở ClickSomo

Danh bạ & sự đồng ý

Một danh sách bạn có thể bảo vệ, không chỉ là một danh sách bạn có

Ai cũng có thể giữ mười nghìn địa chỉ e-mail. Câu hỏi quan trọng — câu hỏi mà cơ quan quản lý, nhà cung cấp và lương tâm của bạn đều hỏi bằng những cách diễn đạt hơi khác nhau — là từng địa chỉ đến từ đâu và trên cơ sở nào bạn được phép viết thư cho nó. ClickSomo biến điều đó thành một dữ liệu được lưu trữ thay vì thứ bạn phải tự dựng lại.

Danh tính là địa chỉ e-mail

Một liên hệ cho mỗi địa chỉ trong mỗi dự án, được cơ sở dữ liệu bảo đảm chứ không dựa vào may mắn. Địa chỉ được chuẩn hoá khi ghi vào, không bao giờ khi đọc ra — nếu chuẩn hoá khi đọc thì ràng buộc chỉ là trang trí, cho phép cả Anna@ lẫn anna@ lọt vào.

Số điện thoại được lưu theo E.164 khi có, nhưng số điện thoại là một thuộc tính, không phải danh tính. Không có đồ thị phân giải danh tính, không có quy trình gộp hồ sơ và không có nhật ký kiểm tra các lần gộp, vì mọi liên hệ ở đây đều đến qua một kênh đã có sẵn địa chỉ: nhập khẩu, biểu mẫu, đăng ký nhận tin, hoặc mã của chính bạn.

Tên được lưu nguyên vẹn

display_name được giữ đúng như đã cung cấp và không bao giờ bị tách thành phần. Việc tách tên là một nhà máy sản xuất lỗi — "van der Berg", "Kim Min-jun", tên đơn, tước hiệu, và mọi quy ước thứ tự không phải kiểu Anh-Mỹ — và một lần tách sai sẽ hiện ra trong thẻ gộp thành "Kính gửi van,", tệ hơn cả việc không cá nhân hoá.

Các phần có cấu trúc chỉ tồn tại cho những nguồn đã cung cấp sẵn chúng ở dạng tách riêng. Không có gì tự suy ra chúng. Và tên mà ai đó tự nhập sẽ không bao giờ bị ghi đè bởi một tệp CSV sau này tình cờ ghi nhận khác đi, vì cơ chế ghi sau thắng sẽ để lần nhập khẩu cẩu thả nhất giành chiến thắng.

Một liên hệNhững gì được lưu
  • 1Danh tínhE-mail, đã chuẩn hoá. Duy nhất trong phạm vi dự án.
  • 2TênLưu nguyên vẹn. first_name được suy ra lúc hiển thị, không bao giờ lưu.
  • 3Thuộc tínhBất cứ gì bạn muốn, dưới dạng JSON. Của bạn, và có thể nội suy dưới dạng attrs.*.
  • 4Thẻ và danh sáchThẻ là đối tượng hạng nhất và nằm trong một kho chung; danh sách là tư cách thành viên tường minh.
  • 5Sự đồng ýMột dòng cho mỗi kênh, kèm cơ sở pháp lý và bằng chứng của nó.
  • 6Sự kiệnNhật ký chỉ-ghi-thêm về mọi thứ người này đã làm. Bảng mà toàn bộ sản phẩm dựa vào.
  • ×Không bao giờKhông mật khẩu, không băm, không phiên đăng nhập, không khoá API. Một cột có thể xác thực ai đó sẽ là một sự cố, không phải một tính năng.

Giới hạn theo tenant và dự án, cả hai

Sổ ghi nhận đồng ý

Không có dữ liệu không có nghĩa là được phép

Một dòng cho mỗi liên hệ trên mỗi kênh — e-mail, SMS, thư, push — mỗi dòng mang một trạng thái, một cơ sở pháp lý, một nguồn, bằng chứng, dấu thời gian và thẩm quyền tài phán. Một liên hệ không có dòng cơ sở cho một kênh thì không thể gửi gì qua kênh đó. Không phải "bị đánh dấu". Mà là không thể.

consent

Ai đó đã chủ động yêu cầu. Một lần gửi biểu mẫu với bằng chứng được lưu, xác nhận kép (double opt-in), một ô kiểm họ tự tích. Đây là cơ sở mạnh nhất và là cơ sở duy nhất mà một biểu mẫu có thể tạo ra.

legitimate_interest

Đây là mức tốt nhất mà một lần nhập CSV có thể đạt. Một bảng tính không thể nhớ việc ai đó đã đồng ý điều gì, nên nó không bao giờ được phép tuyên bố như vậy — và việc tải lại cùng một tệp không nâng cấp cơ sở này.

contract

Bạn liên hệ với họ vì điều mà cả hai bên đều là bên tham gia. Nhắc lịch dịch vụ, thông báo gia hạn, thứ mà họ sẽ khó chịu nếu không nhận được.

Trước khi một chiến dịch được gửi, bạn thấy cơ cấu cơ sở pháp lý của đối tượng nhận: bao nhiêu người trong số này đã yêu cầu, bao nhiêu được tiếp cận dựa trên lợi ích hợp pháp, và bao nhiêu là vì một hợp đồng. Đây là một con số đã ngăn được nhiều lần gửi sai hơn bất kỳ banner cảnh báo nào từng được viết.

Vì sao điều này nghiêm ngặt hơn mức cần thiết đối với bạn: thực ra không phải vì bạn. Uy tín gửi hàng loạt là một tài nguyên chung, và một danh sách bất cẩn sẽ làm ô nhiễm nguồn cho tất cả mọi người gửi từ cùng hạ tầng. Tỷ lệ khiếu nại và thoát (bounce) theo từng tenant được theo dõi, và một tài khoản vượt ngưỡng sẽ bị giới hạn tốc độ ngay tại đây — trước khi nhà cung cấp làm điều đó với tất cả cùng một lúc.

Đằng sau mỗi dòng trong danh sách là một người đã nói có.

Bốn lối vào

Mọi lối vào danh sách của bạn đều là bạn, tác động lên dữ liệu của chính mình

Không có kênh nạp bằng token dịch vụ và không có sản phẩm anh em âm thầm ghi vào danh bạ của bạn. Nếu bạn muốn ai đó vào một danh sách, một trong bốn lối này đã đưa họ vào đó.

Nhập khẩu CSV

Ánh xạ theo từng cột, chuẩn hoá khi ghi, kiểm tra MX để bắt các miền chết hoặc gõ sai trước khi chúng hard-bounce, và được nạp với một cơ sở pháp lý bạn đặt tường minh. Lần nhập khẩu nhận một mã định danh, và mọi liên hệ nó tạo ra đều trỏ ngược về mã đó.

Một biểu mẫu ClickSomo

Được hiển thị từ cùng một tài liệu như mọi thứ khác, với kiểm tra dữ liệu, honeypot và giới hạn tần suất. Một lần gửi biểu mẫu là lối vào duy nhất có thể tạo ra consent một cách chính đáng, vì đó là lối duy nhất mà người dùng thực sự có mặt.

Một trang bạn tự dựng trong dash-b

Trình thiết kế dashboard xuất bản các trang; một biểu mẫu trên một trong các trang đó gửi dữ liệu về đây bằng thông tin xác thực của chính bạn. Cùng cơ chế kiểm tra, cùng cách xử lý sự đồng ý, không cần bảo trì một tích hợp thứ hai.

API công khai

POST /v1/contacts với token của riêng bạn, ngữ nghĩa upsert, tôn trọng khóa idempotency. Ứng dụng của bạn đã biết ai đã đăng ký; đây là con đường ngắn nhất từ sự kiện đó đến một phễu.

Phân khúc là một vị từ, được biên dịch

Một phân khúc là một cây vị từ được lưu lại trên các trường liên hệ, thuộc tính, thẻ, tư cách thành viên danh sách và hành vi, được biên dịch thành SQL và lưu cache kèm số đếm. Các toán tử là những toán tử thông thường — bằng, khác, trong, không trong, bắt đầu bằng, kết thúc bằng, chứa, có giá trị, không có giá trị — kết hợp với and, or và not ở độ sâu tùy bạn cần.

Xem trước trước khi dùng. Endpoint trả về các liên hệ thật, nên câu hỏi "ai thực sự nằm trong đây" được trả lời bằng cách nhìn chứ không phải bằng cách gửi rồi mới biết.

Phân khúc sau đó đảm nhiệm hai vai: làm đối tượng cho một chiến dịch, làm điều kiện trên một nhánh phễu, và làm trình kích hoạt độc lập — segment_enter bắt đầu một lượt chạy ngay khi có ai đó trở nên đủ điều kiện.

Khách quen trầm lặngXem trước phân khúc · 412
  • 1Thẻtags contains "regular"
  • 2Thuộc tínhattrs.total_orders >= 3 — trường của bạn, tên bạn đặt cho nó.
  • 3Hiệu ứngKhông có sự kiện order.paid nào trong 90 ngày qua.
  • 4Sự đồng ýMột cơ sở e-mail dùng được. Những liên hệ không có cơ sở này không được tính vào số đếm, vì dù sao cũng không thể gửi cho họ.
  • iXem trước412 liên hệ, đã liệt kê. Đếm lại lúc gửi, vì một phân khúc là một câu hỏi chứ không phải một ảnh chụp.

Được biên dịch thành SQLSố đếm được cache, câu trả lời luôn mới

Chặn gửi, và khi nào được kiểm tra

Các lệnh chặn gửi thuộc phạm vi dự án và toàn cục: hard bounce, khiếu nại, hủy đăng ký, mục nhập thủ công và địa chỉ vai trò. Chúng được kiểm tra vào lúc gửi, rồi kiểm tra lại bên trong chính dịch vụ gửi thư.

Từ thứ hai mới là điều quan trọng. Một phễu có bước chờ ba ngày sẽ có cửa sổ ba ngày để ai đó hủy đăng ký, và một hệ thống chỉ kiểm tra lệnh chặn khi thông điệp được xếp hàng vẫn sẽ gửi thư cho họ. Kiểm tra lúc gửi chính là sự khác biệt giữa tôn trọng một lượt hủy đăng ký và chỉ ghi nhận nó.

Xóa dữ liệu hoạt động theo cách tương tự: một yêu cầu xóa sẽ loại bỏ liên hệ và lịch sử thông điệp của họ ở đây, và đến được mọi dịch vụ anh em đang giữ bản sao qua cùng một kênh nội bộ mà cả hệ thống sử dụng. Chỉ có một nơi để yêu cầu và một việc duy nhất xảy ra.