Skicka nyhetsbrev gratis? Uppmärksamma och hantera varsamt.

Skicka nyhetsbrev gratis? Uppmärksamma och hantera varsamt.

Allt om allt har nu skrivits om nyhetsbrev. I och med att GDPR träder i kraft har frågan blivit ytterligare komplicerad...

...även om Garanten har gjort känt att det inte föreligger något straffbart och/eller straffbart brott om någon skickar nyhetsbrev utan föregående godkännande av mottagaren.

Jag stötte också på tutorials och artiklar, även av högt ansedda personer som Francesco Giammanco (francescogiammanco.it) om hur man hanterar, organiserar och skapar en DEM-kampanj och/eller hur man skickar nyhetsbrev gratis utan stöd från externa plattformar som Mailchimp etc.

Jag är övertygad om att "gratis" inte finns. Det finns alltid ett pris att betala, förr eller senare och det kan också vara väldigt salt. Jag tror också att gör-det-själv-eran närmar sig sitt slut trots explosionen och framgångarna för många open source CMS som fick oss att tro att den "fria hålan för alla" verkligen var framtiden för marknaden för onlinekommunikation och webbmarknadsföring. Istället är det precis tvärtom.

Så för att komma in på ämnet kopierar jag här, som jag fått den, en kommentar frånEng. Fabio Pagano, VD di SitoVivo vilket förefaller mig djupt spot on ens lite som svar på den fortfarande intressanta artikeln av den mycket bra Francis Giammarco som du hittar här: www.francescogiammanco.it/newsletter-gratuita-wordpress.

Här är kommentaren från Fabio Pagano som jag tackar offentligt.


Artiklar som denna bör föregås av orden "hantera med försiktighet, farlig artikel" eller åtföljas av instruktioner som när det gäller läkemedel som inte är lämpliga för självmedicinering men med receptplikt.

Problemet är att nyhetsbrevet till synes är ett ofarligt problem, lätt att lösa, i verkligheten ligger bakom detta problem en ofta okänd värld.
Det är mycket farligt att tänka på att skicka med wordpress-plugin, speciellt om det är fråga om ett stort antal kontakter eller frekventa sändningar. Förutom tröskelproblemen hos mottagarleverantörerna (som nämns men inte väl utforskade i artikeln), vilket kan leda till att en hel sändande IP blockeras, med åtföljande blockering av den valda värd- eller smpt-tjänsten (gmail eller andra)...

Även om man väljer mer avancerade saker, särskilt för nördar, som mailgun, i själva verket lämnas allt på uppfinnaren av lösningen, förutom resten av ledningen, inklusive integritet och IT-säkerhet. Den minst säkra platsen att lagra en databas på är på en front-end som wordpress ofta utsatt för kontinuerliga intrångsförsök och höga risker, särskilt i frånvaro av periodiska uppdateringar.

Att hantera leveransbarhet via en extern smtp innebär att inte ha total kontroll över vad du gör (med negativa konsekvenser på leveransbarhet eller på sannolikheten att hamna i mottagarens INBOX).

I allmänhet föds allt och är giltigt för ett specifikt ändamål och förblir olämpligt för andra ändamål. Till exempel. en tjänst som gmail är lämplig för att hantera personlig och icke-massiv post. En tjänst som mailgun är giltig för de som vill skicka transaktionsmail och/eller sedan skapa sitt eget hanterings- och underhållsgränssnitt för applikationen som använder den. Andra val (som inte nämns i den här artikeln) är programvara som ska installeras på kundens PC, som omedveten om konsekvenserna börjar skicka med ADSL hemma...

ESP-tjänster är specifika för nyhetsbrevr, massutskick, vissa är lämpliga för autosvar, andra för marknadsföringsautomatiseringsåtgärder. Få eller nästan inga är, "ensamma" utan ändringar eller tillägg, verkligen kompatibla med GDPR för integritet.

Vi skrev en gång, ironiskt nog, en artikel med ett foto av en mormor på omslaget med titeln: "Hur du gör e-postmarknadsföring med det du har hemma".
Det var ironiskt, eftersom alla "ingredienser" som farmor behövde återvinna för att göra denna "rätt" verkligen var för komplexa för att återvinna... Än mindre verktygen för att blanda ihop dem för att få den önskade "rätten".

Men... kunden är så okunnig att artiklar som denna ofta får honom att prova på egen hand (eller nästan) och har hopplöst ont.

  • Enligt min erfarenhet är några anekdoter (som jag har sett med mina egna ögon) som jag tänker på följande:
    byrån som säger: "Fabio, titta, eftersom kunden inte förstår och bara oroar sig om han ser räknaren på servern blockerad eller långsam när han skickar, lägger jag ett skript som modifierar räknaren genom att manipulera den så att efter 5 minuter verkar det som att sändningen är klar för alla adresser, om mejlen kommer eller inte går så bryr han sig inte riktigt, han ser det inte och föredrar att inte betala istället för att se mer exakt statistik..." !!! (Han är en tidigare delägare i mitt företag, kan du föreställa dig varför?)
  • internetanslutning eller värdleverantör som blockerar adsl eller webbplatsen, eftersom du använder deras tjänster mot avtalsspecifikationerna, missbruket av att skicka med den bandbredden och den sändande IP-adressen.
  • Genom att dela sajtens IP med leverans-IP har du ofta bandbredd mättad av sändningen och sajten går långsamt under sändningen eller är inte nåbar alls, och absurt nog var det precis vad kunden ville ha genom att skicka nyhetsbrevet eller snarare de personer som genom att klicka borde ha kommit till hemsidan...
  • integritetsfrågorna förtjänar en separat kommentar, så låt oss först säga att gör-det-själv-kunder har beslutat (medvetet eller inte, det är inte känt) att de inte följer lagen...
    Några exempel på mer frekventa fall, med avseende på eventuell inspektion av integritetsgaranten, kan vara:
  • den enskilde användaren, mottagaren av dina nyhetsbrev klagar, säger att han fortsätter att få e-post trots att han har avslutat prenumerationen 3 gånger...
  • du har inte kontroll över avregistreringar, avvisningshantering eller studsade e-postmeddelanden, som en ESP erbjuder som ett grundläggande alternativ i specialiserade tjänster men är känsliga applikationer som kräver serverresurser
  • kunden har inte gett sitt samtycke till profileringen eller inte hade avregistrerat sig på annat håll och du har inte synkroniserat listorna etc.
  • dedikerade SMTP-tjänster blockerar likaledes konton om de får klagomål eller rapporter från användare som klagar på spam eller myndigheter som integritetsgaranten eller andra missbruk som används och de tar verkligen inte hand om att hantera allt som behövs för hela tjänsten.

Kort sagt, så länge du går till stranden och slottet är gjord av sand, är allt du behöver för att spela en plasthink och spade. När slottet måste stå emot havets vågor kanske bygga det med ett material som är mer motståndskraftigt än sand och använda lämpligare verktyg... (kloka ord... nde)

Jag tänkte säga och kanske låta dig följas av utbildade konsulter, men jag rättade mig direkt: det är sällan någon som inte är specialiserad på e-postmarknadsföring vet hur man hanterar ett nyhetsbrev, oftare använder han någon tjänst utifrån dess kostnader, litar på och förlitar sig på den, utan att veta om och vilka gränser det har.


Än sen då?

Och därför bör den som skickar nyhetsbrev göra fördjupade studier och utbildning för att åtminstone ha en grund i åtanke om eventuella problem, annars är det bättre att han inte gör någonting.

Verklighet?

Precis som sajter med wordpress gör och sedan inte gör något underhåll så att de utsätts för minimala säkerhetsrisker, gör de samma sak med nyhetsbrev, gör-det-själv eller till låg kostnad, medan det idag hanterar kunddata (inklusive öppningsstatistik, klick på länkar och vad de sedan såg på sajten) är den nya oljan, som måste förvaras som en skatt med en säker och dubbellåst nyckel...
Och framför allt bör enskilda användares beteenden inom ett nyhetsbrev och inom en webbplats användas för att personifiera innehållet i meddelandena (beteendebaserad webbmarknadsföring), och på så sätt optimera avkastningen på investeringen i tid och pengar för att skicka ett nyhetsbrev och allt annat runt det.