# Cách tạo chuỗi email onboarding ngay từ Cursor

URL chính tắc: https://brew.new/vi/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Tác giả: Philip Sørensen
Ngày đăng: 2026-09-25
Ngày cập nhật: 2026-09-29

Email onboarding phụ thuộc vào chính dữ liệu sự kiện mà sản phẩm của bạn dùng. Làm việc từ Cursor cho phép bạn rà soát trình xử lý đăng ký, tạo trình kích hoạt tương ứng trong Brew và kiểm tra email ở cùng một nơi. Hãy giao cho một người chịu trách nhiệm xuất bản luồng và phê duyệt các lượt gửi thực tế.

## Kết nối Brew

Thêm máy chủ này trong phần cài đặt MCP của Cursor hoặc trong tệp `.cursor/mcp.json` của dự án:

```json
{
  "mcpServers": {
    "brew": { "url": "https://brew.new/api/mcp" }
  }
}
```

Hoàn tất bước đăng nhập OAuth của Brew và chọn đúng thương hiệu cần dùng. Yêu cầu agent gọi `get_brew_capabilities`. Nếu client của bạn dùng định dạng cấu hình khác, hãy làm theo [hướng dẫn thiết lập client](https://docs.brew.new/api-reference/mcp/connect-your-client). Đừng để bất kỳ khóa API nào xuất hiện trong đoạn chat hay kho mã.

## Xác định riêng điều kiện cho email đăng ký và email nhắc

Yêu cầu Cursor tìm đoạn mã ghi nhận (commit) một tài khoản mới. Hãy quyết định thế nào được tính là kích hoạt, chẳng hạn tạo dự án đầu tiên. Hướng dẫn này đặt các bước kiểm tra điều kiện trong ứng dụng và dùng hai trình kích hoạt riêng biệt:

- Một trình kích hoạt đăng ký cho email chào mừng gửi ngay.
- Một trình kích hoạt email nhắc cho người đủ điều kiện, chỉ được ứng dụng gọi sau khi đã kiểm tra trạng thái kích hoạt hiện tại.

Dùng `save_trigger` để định nghĩa từng payload, gồm cả chuỗi email bắt buộc. Hãy lưu lại đúng các ID trình kích hoạt được trả về. Một tên hiển thị như `user_signed_up` không thể thay thế cho định danh API.

## Tạo và rà soát email

Một bản brief đầu tiên hữu ích:

```text
Create a welcome email for a new account.
One action: create a first project at https://app.example.com/projects/new.
Use the brand already selected in Brew. Do not invent statistics or testimonials.
Create a separate setup-reminder email for recipients our app confirms have not activated.
Leave both automations as drafts for review.
```

Agent có thể dùng `create_email`, `edit_email` và `save_automation`. Hãy mở kết quả trong Brew và kiểm tra bố cục, nội dung, liên kết và tên miền gửi. Hãy dùng [cú pháp thẻ cá nhân hóa](https://docs.brew.new/create-emails/merge-tags) theo tài liệu, kèm một giá trị dự phòng đã được kiểm thử cho trường hợp thiếu tên.

Đừng đặt bộ lọc `activated is false` trên một đường đi tuyến tính trước một email tiếp nối dành cho `activated is true`. Một bộ lọc không đạt sẽ dừng mọi bước phía sau nó. Các trường sự kiện như `payload.activated` vẫn giữ nguyên giá trị sau một bước chờ. Thay cho công thức dựa vào lịch của ứng dụng này, bạn có thể định nghĩa và đồng bộ một trường liên hệ kiểu Có/Không rồi kiểm tra `contact.activated` sau mỗi bước chờ liên quan. Điều kiện đó đọc dữ liệu liên hệ hiện tại trong Brew, không phải cơ sở dữ liệu ứng dụng của bạn. Xem [hướng dẫn về chuỗi email dùng thử](/vi/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Kết nối backend

Lấy định nghĩa payload của từng trình kích hoạt bằng `get_trigger_contract`, hoặc tạo định nghĩa bằng [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Gọi trình kích hoạt đăng ký sau khi giao dịch tạo tài khoản đã được commit.

Ví dụ shell sau giả định `BREW_SIGNUP_TRIGGER_ID` chứa định danh được trả về khi bạn tạo trình kích hoạt, và lược đồ của trình kích hoạt có khai báo `firstName`:

```bash
curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_SIGNUP_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: signup-example-account-123" \
  -d '{"payload":{"email":"alex@example.com","firstName":"Alex"}}'
```

Dùng một khóa ổn định cho mỗi sự kiện đăng ký, giữ nguyên khóa đó khi thử lại, và kiểm tra các phản hồi lỗi. Hãy làm theo [quy ước về tính lũy đẳng của API](https://docs.brew.new/api-reference/api/idempotency).

Khi đến hạn gửi email nhắc, ứng dụng của bạn đọc trạng thái hiện tại của tài khoản. Nếu người dùng đã kích hoạt, đã bị xóa hoặc không còn đủ điều kiện vì lý do khác, ứng dụng sẽ không gọi trình kích hoạt email nhắc. Ngược lại, ứng dụng gửi một sự kiện mới với dữ liệu hiện tại. Chỉ cập nhật trường liên hệ thôi thì không hủy được lượt chạy ban đầu.

## Kiểm thử trước khi xuất bản

Dùng `test_automation` với những người nhận bạn kiểm soát được. Xem [cách chạy thử hiện tại](https://docs.brew.new/create-emails/build-an-automation) và kiểm tra lịch sử thực thi. Hãy kiểm thử cả bộ lập lịch của ứng dụng:

1. Một tài khoản mới nhận email chào mừng đúng một lần.
2. Một tài khoản chưa kích hoạt tạo ra đúng một sự kiện nhắc nhở đủ điều kiện.
3. Một tài khoản đã kích hoạt trước lần kiểm tra theo lịch không tạo ra sự kiện nhắc nhở nào.
4. Một lần thử lại không tạo thêm lượt gửi.
5. Trường bị thiếu hoặc không hợp lệ tạo ra một lỗi mà backend của bạn ghi lại và xử lý.

Hãy xem lại mục đích của tên miền gửi và các yêu cầu về sự đồng ý. Sau đó, xuất bản một cách tường minh bằng `save_automation` với `published: true`. Một tự động hóa đã xuất bản có thể chạy khi có sự kiện thật.

Để thiết kế chuỗi email ở góc độ rộng hơn, hãy xem [chuỗi email chào mừng](/vi/blog/welcome-email-sequence). Để chọn giao diện lập trình mà backend của bạn sử dụng, hãy xem [MCP hay REST](/vi/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).