Dostawca może akceptować Twój miesięczny wolumen, a mimo to ograniczać burst po awarii procesu zakupowego. Porównaj warunki wysyłki z pracą, którą Twoja aplikacja musi odzyskać.
Czym jest transakcyjna poczta e-mail?
Transakcyjna poczta e-mail obsługuje transakcję lub aktywność konta odbiorcy, na przykład potwierdzenie zakupu lub reset hasła. Kategoria wiadomości wynika z jej celu. Liczba odbiorców ani automatyczne wyzwalanie nie czynią treści promocyjnych transakcyjnymi.
Co powinieneś ocenić?
Porównaj możliwości potrzebne Twojej aplikacji, a potem przetestuj ścieżki awarii przed podjęciem zobowiązania.
- Dostarczalność i narzędzia reputacji. Czy możesz łatwo uwierzytelnić swoją domenę za pomocą SPF, DKIM i DMARC? Czy dedykowane IP są dostępne, jeśli ich potrzebujesz, wraz ze wskazówkami dotyczącymi ich rozgrzewania?
- Jakość API i SDK. Czy API jest dobrze udokumentowane, z oficjalnymi SDK w językach, których używasz?
- Zarówno SMTP, jak i HTTP. Sprawdź, który interfejs wysyłki obsługuje Twoje środowisko uruchomieniowe. Istniejące klienty SMTP mogą korzystać z relay; HTTP API obsługuje aplikacje wysyłające ustrukturyzowane żądania.
- Szablony. Szablony po stronie serwera z podstawianiem zmiennych pozwalają zmieniać treść bez wdrożenia i utrzymywać spójne formatowanie we wszystkich wiadomościach.
- Webhooki i zdarzenia. Zdarzenia webhook w czasie rzeczywistym dotyczące dostarczenia, otwarcia, kliknięcia, odrzucenia i skargi pozwalają utrzymywać dokładność własnych rekordów i uruchamiać logikę następczą.
- Analityka. Zagregowane widoki wskaźników dostarczenia, odrzuceń i zaangażowania, a także przeszukiwalny log do badania pojedynczej wiadomości.
- Obsługa supresji. Dostawca powinien automatycznie wstrzymywać wysyłkę po twardych odrzuceniach i skargach, aby Twoja aplikacja mogła zaprzestać wysyłek blokowanych przez te sygnały. Zapytaj, jak zarządzane są listy supresji i czy możesz je przeglądać.
- Skalowalność. Czy poradzi sobie ze szczytowym wolumenem (premiera produktu, świąteczny skok) bez ręcznej interwencji i niespodziewanego ograniczania przepustowości?
- Cennik. Zrozum model rozliczeniowy (za wiadomość, progowy, z wliczonym wolumenem) i od kiedy naliczane są nadwyżki. Oblicz koszt dla przewidywanego wolumenu i okresów szczytowych.
- Wsparcie. Kiedy poczta przestaje przepływać o 2:00 w nocy, jak docierasz do człowieka i jak szybko odpowiada? Sprawdź poziom wsparcia dostępny w planie, który faktycznie kupisz.
- Zgodność. Potwierdź, że dostawca spełnia wymagania dotyczące przetwarzania danych i wymogi regionalne, którym podlega Twoja firma, zanim się zobowiążesz.
Kiedy wybrać usługę relay SMTP?
Wybierz relay SMTP, gdy Twoja aplikacja już buduje wiadomości e-mail i obsługuje konfigurowalny serwer pocztowy. Wybierz HTTP API, gdy potrzebujesz ustrukturyzowanych pól żądania lub zapisanych szablonów.
W przypadku Bird porównaj ścieżki wysyłki i odzyskiwania przed wyborem interfejsu:
| Decyzja lub awaria | Relay SMTP | HTTP email API |
|---|---|---|
| Uwierzytelnianie | Nazwa użytkownika bird, klucz API jako hasło, z zakresem emails. Użyj TLS na regionalnym hoście SMTP. | Klucz API w nagłówku Authorization: Bearer, z zakresem emails. |
| Odpowiedź na wysyłkę | Końcowy 250 zawiera ID zakolejkowanej wiadomości. Zapisz go razem ze zdarzeniem aplikacji. | 202 zawiera ID zaakceptowanej wiadomości. Zapisz go razem ze zdarzeniem aplikacji. |
| Odpowiedzialność za ponowienie | Twoja aplikacja lub klient SMTP obsługuje ponowienia wysyłki. Użyj ponownie X-Bird-Idempotency-Key dla tej samej wiadomości logicznej. | Twoja aplikacja lub SDK obsługuje ponowienia wysyłki. Użyj ponownie Idempotency-Key dla tej samej wiadomości logicznej. |
| Wygaśnięcie | Przed ponowieniem niewysłanego zadania Twoja aplikacja sprawdza, czy link lub kod jest nadal ważny. | Zastosuj to samo sprawdzenie przed wysłaniem kolejnego żądania. |
| Założenia przepustowości | Sprawdź limity jednoczesnych połączeń osobno od limitów wysyłki. Więcej otwartych połączeń nie ustanawia limitu szybkości wysyłki. | Kontroluj tempo żądań API za pomocą nagłówków rate-limit z odpowiedzi. Szybkość żądań i wolumen odbiorców to różne wielkości. |
| Dowody zdarzeń | Śledź zdarzenia odbiorcy po odpowiedzi o zakolejkowaniu. Bird ponawia odroczone dostarczenie. | Śledź te same zdarzenia odbiorcy po zaakceptowaniu. Bird ponawia odroczone dostarczenie. |
| Wybór puli | Konfiguracja SMTP klucza API wybiera pulę. Nieskonfigurowany klucz używa domyślnej puli organizacji. | Ustaw ip_pool_id per wysyłka lub użyj domyślnej puli organizacji. |
Przewodnik relay SMTP zawiera ustawienia połączenia i obsługę odpowiedzi. Dokumentacja wysyłki HTTP definiuje żądanie i odpowiedź API. Oba interfejsy korzystają z tego samego pipeline'u e-mail, w tym obsługi supresji i podpisywania.
Akceptacja transportowa oznacza, że Bird zakolejkował wiadomość. Późniejsze zdarzenie email.delivered oznacza, że serwer odbiorczy ją zaakceptował. Żadne z nich nie gwarantuje dostarczenia do skrzynki ani odczytania.
Przechowuj własny rekord wysyłki poza oknem retencji idempotentności, ponieważ późniejsze ponowienie może utworzyć kolejną wiadomość. Odroczenie jest już ponawiane przez Bird; utworzenie kolejnej wysyłki duplikuje pracę wciąż w toku.
Dedykowane IP są opcjonalne dla obu interfejsów. Sprawdź wymagania dotyczące puli i rozgrzewania przed kierowaniem burstu przez dedykowaną pulę.
Które opublikowane możliwości porównać?
Sprawdź udokumentowany interfejs stojący za każdą funkcją. Odbieranie sparsowanej wiadomości e-mail, przechowywanie jej treści i udostępnianie API konwersacji to różne możliwości.
| Dostawca | Wysyłka | Dowody dotyczące odbiorcy | Infrastruktura odbiorcza i nadawcza |
|---|---|---|---|
| Bird | Wysyłka HTTP i SMTP | Zdarzenia, log wiadomości i supresje | Skrzynki i wątki; dedykowane pule IP |
| Amazon SES | SendEmail API i SMTP | Miejsca docelowe zdarzeń i lista supresji konta | Reguły odbioru w obsługiwanych regionach; standardowe lub zarządzane dedykowane IP |
| SendGrid | Mail Send API i SMTP | Event Webhook i Email Activity | Inbound Parse webhook; pule IP |
| Mailgun | Messages API i SMTP | Zdarzenia dostarczenia i rekordy odrzuceń | Trasy do przekazywania lub przechowywania poczty; pule IP |
| Postmark | Email API i SMTP | Webhooki i supresje strumienia | Webhook przychodzący; kwalifikowalność dedykowanego IP |
| Resend | Email API i SMTP | Zdarzenia webhook i logi API | Odebrana treść i odpowiedzi; zarządzane dedykowane IP |
Potwierdź kwalifikowalność i retencję dla planu, który zamierzasz kupić. Link do funkcji nie ustanawia limitu przepustowości ani zobowiązania dotyczącego czasu odzyskiwania.
W przypadku przechowywanych treści sprawdź, które treści wiadomości, nagłówki, załączniki i rekordy zdarzeń pozostają dostępne. W przypadku rezydencji danych uzyskaj opublikowany zakres przechowywania i przetwarzania, łącznie z wyjątkami. Sam regionalny endpoint nie ustanawia tego kontraktu.
Co się zmienia przy dziesięciu milionach wysyłek miesięcznie?
Szczytowy ruch i zdolność odzyskiwania wyznaczają wymaganą szybkość wysyłki. Sam miesięczny wolumen nie wystarcza.
W przykładowym 30-dniowym miesiącu dziesięć milionów wiadomości z jednym odbiorcą to średnio ok. 3,86 wiadomości na sekundę. Burst 100 000 wiadomości w dziesięć minut wymaga ok. 167 na sekundę. Oceniaj burst osobno od miesięcznego limitu.
Po dziesięciominutowej przerwie przy 100 nowych wiadomościach na sekundę Twoja aplikacja ma 60 000 niewysłanych zadań. Jeśli nowe zadania nadal napływają z tempem 100 na sekundę, nadrobienie zaległości w dwadzieścia minut wymaga dodatkowych 50 na sekundę. Cel odzyskiwania to zatem 150 zaakceptowanych wiadomości na sekundę, przed ponowieniami i opóźnieniami serwera odbiorczego.
Sprawdź, jak każdy dostawca liczy pracę. Limity SES liczą odbiorców i obowiązują osobno per region. Obejmują kroczący limit dzienny oraz szybkość akceptacji. SES ostrzega też, że faktyczna akceptacja może być niższa od maksymalnej szybkości konta.
Limity Resend rozróżniają szybkość żądań API od limitów wolumenu e-mail. Nagłówki rate-limit Bird raportują efektywny limit żądań. Przelicz wielkość wsadu na żądania, zanim porównasz którykolwiek z nich ze scenariuszową szybkością odbiorców.
Jak testować odzyskiwanie po incydencie?
Przetestuj, jak Twoja aplikacja wznawia pracę po niepowodzeniu wysyłki lub gdy handler webhooków staje się niedostępny. Strona statusu dostawcy dostarcza kontekstu incydentu; Twoje rekordy wiadomości ustalają, jaka praca pozostała.
| Dostawca | Opublikowany limit lub kontrakt błędów | Oficjalny status |
|---|---|---|
| Bird | Efektywne limity i nagłówki ponowień | Status Bird |
| Amazon SES | Limity wysyłki | Stan usług AWS |
| SendGrid | Limity szybkości API | Status SendGrid |
| Mailgun | Kontrakt błędów i rate-limit API | Status Mailgun |
| Postmark | Kontrakt odpowiedzi i błędów API | Status Postmark |
| Resend | Limity użycia | Status Resend |
Wstrzymaj testowy worker, nagromadź zadania i wznów w ramach efektywnego limitu konta. Zmierz, jak długo czeka najstarsze kwalifikujące się zadanie. Wygasłe zadania resetu wymagają ścieżki nowego żądania zamiast automatycznego powtórzenia.
Zachowaj każdy identyfikator zdarzenia biznesowego podczas odzyskiwania. Zweryfikuj kontrakt dostawcy dotyczący duplikowania wysyłek przed ponowieniem niepewnej wysyłki. Postmark nie dokumentuje funkcji klucza idempotentności, więc jego integracja wymaga zabezpieczeń po stronie aplikacji. Retencja zakończonych odpowiedzi Bird wynosi trzy godziny. Odzyskiwanie po tym oknie wymaga własnego rekordu zdarzeń.
Dopasuj późniejsze zdarzenia odbiorcy do zapisanych ID wiadomości. Akceptacja przez serwer odbiorczy nie gwarantuje dostarczenia do skrzynki ani odczytania. Cykl życia transakcyjnego API wyjaśnia te odrębne wyniki.
Co uwzględnić w porównaniu cen?
Porównaj opublikowane elementy wliczone w cenę dla dokładnego planu, okresu rozliczeniowego i waluty, które zamierzasz wybrać. Rozdziel wolumen wysyłki od infrastruktury i retencji, których wymaga.
| Źródło cennika dostawcy | Elementy do sprawdzenia dla Twojego obciążenia |
|---|---|
| Cennik Bird | Limit wysyłki, nadwyżki, dedykowana infrastruktura, przechowywane treści i wsparcie |
| Cennik Amazon SES | Użycie wychodzące i przychodzące, opłaty za dane, dedykowane IP i opcjonalne funkcje |
| Cennik SendGrid | Wolumen planu, nadwyżki, kwalifikowalność dedykowanego IP, retencja aktywności i wsparcie |
| Cennik Mailgun | Wolumen wysyłki, retencja logów i wiadomości, dedykowane IP i wsparcie |
| Cennik Postmark | Limit wysyłki, dodatkowy wolumen, opcje retencji i kwalifikowalność dedykowanego IP |
| Cennik Resend | Limity wysyłki i odbioru, nadwyżki, retencja i kwalifikowalność dedykowanego IP |
Sprawdź, czy podany limit liczy żądania, wiadomości czy odbiorców. Zapisuj wyłączone funkcje obok planu zamiast zakładać, że są wliczone. Porównania dostawców Bird zawierają osobne porównania produktów.
Najczęściej zadawane pytania
Czym różni się transakcyjna poczta e-mail od marketingowej?
Transakcyjna poczta obsługuje transakcję lub aktywność konta. Marketingowa poczta promuje coś lub dostarcza subskrybowane treści. Cel wiadomości wyznacza to rozróżnienie, także gdy oba rodzaje są zautomatyzowane.
Czy jeden dostawca może obsłużyć zarówno pocztę transakcyjną, jak i marketingową?
Dostawca może obsługiwać oba przepływy. Sprawdź osobno politykę kategorii, uwierzytelnione tożsamości nadawcze i wybór puli IP. Współdzielona infrastruktura może wciąż narażać pocztę operacyjną na problemy reputacji wynikające z ruchu marketingowego.
Czy potrzebuję dedykowanego IP?
Nie na początku. Współdzielone pule IP wystarczają przy niższych wolumenach i oszczędzają Ci rozgrzewania IP. Dedykowany IP ma sens, gdy Twój wolumen jest wystarczająco duży i stabilny, aby utrzymywać własną reputację. Wybierz dostawcę, który pozwala zacząć na współdzielonej puli i przejść na dedykowaną, gdy liczby to uzasadnią.
Miejsce Bird
Możesz wysyłać przez SMTP lub HTTP API. Publikuj szablony dla treści wielokrotnego użytku. Subskrybuj zdarzenia odbiorcy. Przeglądaj poszczególne wiadomości w logu e-mail.
Wybieraj pule IP niezależnie od kategorii wiadomości. Postępuj zgodnie ze wskazówkami rozgrzewania przy zmianie wolumenu wysyłki. Użyj listy kontrolnej operacyjnej, aby przetestować obsługę duplikatów i odzyskiwanie.
Jak podjąć ostateczną decyzję?
- Dopasuj udokumentowane interfejsy i mechanizmy kontroli odbiorców do swojej aplikacji.
- Potwierdź efektywne limity zarówno dla szczytowego ruchu, jak i odzyskiwania zaległości.
- Przetestuj obsługę awarii względem zapisanych rekordów wiadomości i zdarzeń biznesowych.
- Porównaj opublikowane elementy wliczone w cenę, retencję i wsparcie dla planu, który zamierzasz kupić.