Nhóm SaaS và sản phẩm
Sản phẩm của bạn biết những điều mà không công cụ marketing nào quan sát được
Ai đã hoàn thành onboarding và ai bị kẹt ở bước ba. Ai đã mời một đồng nghiệp. Ai chạm giới hạn hai lần tuần này. Ai đã không mở cái đó trong hai tuần. Mỗi điều đó đều là một điều kiện kích hoạt tốt hơn bất cứ thứ gì suy ra từ việc mở email, và tất cả chỉ cách việc trở thành như vậy hai dòng code.
Sự kiện là toàn bộ việc tích hợp
POST /v1/events với token của riêng bạn: một tên bạn chọn, một liên hệ, một payload, một khóa idempotency. Đó là toàn bộ kết nối. Không có SDK phải cập nhật, không có màn hình ánh xạ, và không có bộ từ vựng của chúng tôi mà bạn phải dịch sản phẩm của mình sang.
Mỗi sự kiện được ghi vào nhật ký chỉ-ghi-thêm của liên hệ, và từ đó nó đồng thời là ba thứ. Một điều kiện kích hoạt, để một phễu bắt đầu khi nó đến. Một điều kiện, để một phân đoạn có thể nói "đã làm việc này trong mười bốn ngày qua" hoặc, hữu ích hơn, "chưa làm". Và một mục tiêu, để một chuỗi kết thúc ngay khoảnh khắc ai đó làm được điều mà nó đang nhắc nhở họ hướng tới.
Chính thứ ba đó khiến thông báo vòng đời trở nên dễ chịu khi nhận. Lời nhắc hoàn tất thiết lập tài khoản nên ngừng tồn tại ngay giây phút tài khoản được thiết lập xong, và trong hầu hết các công cụ nó không làm vậy, vì chuỗi và sản phẩm không nói chuyện với nhau.
- ⚡Trình kích hoạt
api_event—signup.completed, góifree. - 2Gửi emailChỉ một việc cần làm đầu tiên. Không phải một chuyến tham quan mười một tính năng.
- 3Chờ 2 ngày
wake_attrên lần chạy. Không có gì được xếp hàng, không có gì phải gỡ ra nếu bạn viết lại điều này vào ngày mai. - ?Điều kiện
project.createdđã đến chưa? Chưa → nhánh hỗ trợ. Rồi → mục tiêu bên dưới. - 4Nhánh hỗ trợMột tin nhắn, đề cập cụ thể điều họ chưa làm. Sau đó chờ thêm một lần nữa.
- 5Mục tiêu
project.createdđến. Chuỗi kết thúc. Không còn email onboarding nào nữa, mãi mãi, cho người này.
Tên sự kiện của bạnĐịnh nghĩa "kích hoạt" của bạn
Năm phễu
Vòng đời, theo đúng thứ tự nó thực sự diễn ra
1 · Kích hoạt
Kích hoạt: đăng ký. Hai hoặc ba tin nhắn, mỗi tin về một hành động, mỗi tin có một mục tiêu kết thúc chuỗi khi hành động đó xảy ra. Đây là phễu giá trị nhất bạn sẽ xây dựng, và cũng là phễu đáng viết lại ba lần nhất.
2 · Giai đoạn chững lại
Kích hoạt: segment_enter — đã đăng ký, không có sự kiện nào đáng kể trong bảy ngày. Một tin nhắn hỏi thay vì bảo, và một tin đề nghị một thứ cụ thể. Rồi dừng lại. Tin nhắn thứ tư gửi cho người đã bỏ qua ba tin là tin nhắn gửi cho không ai cả.
3 · Thời điểm mở rộng
Kích hoạt: một sự kiện cho thấy họ đang nhận được giá trị — chạm giới hạn, mời đồng nghiệp thứ ba, xuất dữ liệu lần thứ hai. Đây là thời điểm duy nhất mà tin nhắn nâng cấp được chào đón, và là thời điểm sản phẩm của bạn có thể gọi tên chính xác.
4 · Gia hạn và đòi nợ
Kích hoạt: date_field trước ngày gia hạn, hoặc một sự kiện thanh toán. Thông báo, nhắc nhở, và — nếu thanh toán thất bại — một chuỗi ngắn dừng lại ngay lập tức khi thành công. Node mục tiêu không phải là tùy chọn trong đòi nợ; chúng là ranh giới giữa một lời nhắc và sự quấy rối.
5 · Giữ chân khách rời đi
Kích hoạt: segment_enter — đã hủy hoặc ngủ đông sáu mươi ngày. Hai tin nhắn, chân thành, rồi gắn thẻ và im lặng. Tin nhắn về những gì đã thay đổi kể từ khi họ rời đi tốt hơn một tin giảm giá.
Và cái nội bộ
notify_team báo cho một con người khi một tài khoản đáng để con người quan tâm vượt qua một ngưỡng. Phễu không nhất thiết phải kết thúc bằng một email gửi khách hàng; đôi khi hành động đúng là bảo ai đó ở phía bạn cầm máy gọi điện.
Không ai rời bỏ một cách chủ ý. Họ chỉ ngừng mở nó ra thôi.
Vì sao một lập trình viên có thể thực sự thích thứ này
Những phần quan trọng khi chính bạn là người tích hợp
Không có endpoint riêng tư
Mọi màn hình đều có thể xây dựng từ API công khai, vì không tồn tại loại nào khác. Nếu bạn muốn nhúng báo cáo chiến dịch vào trang quản trị của mình, không có gì cản đường bạn và không phải đảo ngược kỹ thuật thứ gì cả.
Khóa idempotency ở khắp mọi nơi
Trên mọi route làm thay đổi dữ liệu. Logic retry của bạn, hàng đợi at-least-once của bạn và mạng chập chờn của bạn đều trở thành vấn đề của người khác — cụ thể là vấn đề của một unique index.
Mô phỏng trước khi triển khai
POST /v1/simulate chạy thử một contact qua một phễu và trả về đường đi cùng mọi tin nhắn nó sẽ gửi. Đưa nó vào CI nếu bạn muốn: phễu là một đồ thị, và đồ thị thì có thể kiểm thử được.
Một máy chủ MCP
Trỏ một agent vào /mcp và để nó soạn và kiểm tra phễu. Các công cụ có khả năng gửi cần xác nhận rõ ràng và bị giới hạn bởi hạn mức, nên một prompt đọc sai không thể biến thành năm mươi nghìn email.
Webhooks ra
Có chữ ký, retry với backoff, ít nhất một lần. Cùng bộ từ vựng sự kiện mà các báo cáo dùng, nên kho dữ liệu và dashboard của bạn không bất đồng về ý nghĩa của "đã gửi".
Xóa dữ liệu thực sự đến nơi
Một yêu cầu xóa sẽ xóa contact và lịch sử tin nhắn của họ ở đây, và lan tỏa đến mọi dịch vụ anh em đang giữ một bản sao. Một yêu cầu, một kết quả, và một thứ bạn có thể chỉ vào khi bị hỏi.
Ranh giới nằm ở đâu
ClickSomo giữ một danh sách gửi thư và những gì danh sách đó đã làm. Nó không phải là cơ sở dữ liệu người dùng của bạn và cũng không cố trở thành vậy: một contact không bao giờ mang thông tin xác thực, không bao giờ đăng nhập, và không bao giờ trở thành một tài khoản. Người dùng của bạn sống trong sản phẩm của bạn; contact sống ở đây, và hai bên được nối với nhau bằng một địa chỉ email và những sự kiện bạn chọn gửi.
Sự tách biệt đó là có chủ đích và đó là lý do mô hình đồng thuận hoạt động. Bạn là bên kiểm soát dữ liệu cho người dùng của mình; chúng tôi xử lý thay mặt bạn. Một thiết kế mà công cụ marketing lặng lẽ trở thành kho định danh là một thiết kế không thể gỡ rối về sau, và đó chính là thất bại mà thiết kế này được xây dựng để tránh.
Phiên bản thực tế: gửi các sự kiện, gửi các thuộc tính bạn muốn phân khúc theo, và giữ mọi thứ khác ở nguyên chỗ. Nếu bạn thấy mình đang đẩy toàn bộ schema vào đây, thì phân khúc bạn đang cố xây có lẽ là một truy vấn trong cơ sở dữ liệu của chính bạn, nên được gửi đến dưới dạng một thuộc tính boolean duy nhất.