Miért éri meg saját magadnak küldeni a hírleveleidet?

A hírlevél-platformok temetője

Emlékszel még a Tinyletterre? Aki az elmúlt években rendszeresen írt, az biztosan találkozott vele. Egyszerű, letisztult eszköz volt, ami pont azt csinálta, amire kellett: írtál, küldted, az olvasók pedig megkapták. Semmi bonyolult marketinges cucc, csak a lényeg.

Aztán 2024 februárjában a Mailchimp (vagyis az Intuit) egyszerűen megszüntette. Ez is csak megerősítette, amit már sokan sejtettünk: ha ingyen használod a szolgáltatást, vagy nem vagy a fő célközönség, akkor bármikor kitesznek az ajtón, amikor a cégnek más prioritásai lesznek.

Ez a minta egyre gyakoribb. Éppen ezért sok független alkotó és fejlesztő dönt úgy, hogy inkább saját maga oldja meg a hírlevél-küldést.

A harmadik féltől való függés buktatói

Elsőre logikusnak tűnik: valaki más kezeli az SPF rekordokat, a DKIM kulcsokat, a visszapattanó emaileket és a kézbesítési problémákat. Nem kell ezzel bajlódni.

A gond az, hogy ezek a platformok elsősorban marketingeseknek készülnek, nem íróknak. A sablonok, a követőkódok, az elköteleződés-mérés mind arra szolgál, hogy konverziót optimalizáljanak. Te viszont csak azt akarod tudni, hogy elolvasták-e, amit írtál.

Ráadásul az előfizetők száma alapján számláznak, ami egy kisebb, de hűséges olvasótábor esetén is drága lehet. És ha kilépsz a tipikus használati mintából, már nem vagy fontos nekik.

A legnagyobb kockázat mégis az, hogy az olvasóidat valaki más szerverén tárolod. Ha a szolgáltatás megszűnik, újrakezdheted.

Saját infrastruktúra, saját szabályok

A saját megoldás nem feltétlenül jelent bonyolult szerverüzemeltetést. Inkább arról szól, hogy tudatosabban építed fel a rendszert.

A gyakorlatban ez általában így néz ki:

• A tartalmat sima markdown fájlokban tárolod egy Git repóban. Minden kiadás egy fájl, a konfiguráció pedig verziókezelhető és átvihető.
• Küldésre egy API-t használsz, például Postmark, Resend vagy Mailgun szolgáltatást. Ezek kezelik a kézbesítést, a visszapattanásokat és a hírlevél-specifikus követelményeket.
• Egy egyszerű parancssoros eszköz köti össze a markdown fájlokat a küldő API-val. Nincs webes felület, csak te, a terminál és a szövegszerkesztő.
• A kinézet egyszerű marad. Egy sima szöveges email gyakran személyesebb és hatásosabb, mint a túldizájnolt sablonok.

Hogyan épül fel egy ilyen rendszer?

Egy tipikus felépítés valahogy így nézhet ki:

newsletter/
├── issues/              # Egy .md fájl kiadásonként
│   ├── 1.md
│   ├── 2.md
│   └── 3.md
├── subscribers.csv      # Olvasók listája
├── send/                # Küldő szkript
│   ├── send.py
│   └── config.yaml
├── web/                 # Feliratkozási űrlap
│   └── subscribe.py
└── .github/workflows/   # Automatizálás
    └── backup.yaml

Minden fájl nálad van. Ha másik küldőszolgáltatásra váltasz, csak a konfigurációt módosítod. Ha új funkciót szeretnél, a saját kódbázisodba építed be.

A kézbesítés kérdése

Sokan félnek attól, hogy a saját küldés spambe kerül. Valóban kell foglalkozni az SPF, DKIM és DMARC beállításokkal, de ezt nem egyedül kell megoldanod. A küldőszolgáltatók erre specializálódtak – ők kezelik a domain reputációt és a szűrési szabályokat.

A lényeg inkább az, hogy ha hosszabb szünet után írsz, akkor őszintén kommunikálj az olvasókkal. Egy egyszerű üzenet, hogy „elnézést a hosszabb csendért”, gyakran többet ér, mint bármilyen technikai trükk.

Mennyibe kerül ez?

Nem ingyen van, de olcsó. Egy küldőszolgáltatás általában ezer emailenként 1-2 dollárba kerül kisebb mennyiség esetén. Ez kevesebb, mint egy kávé. Ráadásul független alkotóknál ritkán van napi küldés, így a karbantartás sem nagy teher.

Miért éri meg mégis?

Azért, mert a saját csatornádat irányítod. Nem bérelsz helyet valaki más platformján, ahol bármikor változhat a szabályrendszer. Az olvasóiddal közvetlen kapcsolatod van, amit nem befolyásol algoritmus vagy üzleti döntés.

A szükséges eszközök pedig ma már elérhetőek. Olcsó felhőszolgáltatások, érett open source megoldások és egyszerű telepítési lehetőségek állnak rendelkezésre.

Hol kezdj hozzá?

Ha fontolgatod a váltást, érdemes először átgondolni a jelenlegi helyzetet: hol tárolod az olvasói listát, van-e biztonsági mentés, és mi történne, ha a jelenlegi szolgáltatásod megszűnne.

Ezután válassz küldőszolgáltatást az API minősége és az ár alapján. Kezdd egyszerűen – egy mappányi markdown fájllal, egy parancssoros eszközzel és egy feliratkozási végponttal. A rendszer később bővíthető.

A lényeg, hogy az olvasóidnak olyan csatornát adj, ami nem tűnik el egyik napról a másikra.