Autorius: admin

„Ortto” (Autopilot) customer data platforma

by adminin Dirbtinis intelektas, E-komercijaLeave a Comment on „Ortto” (Autopilot) customer data platforma

Kai viena platforma keičia pusę marketing stack’o

Jei dirbi su klientų duomenimis ir marketingu, turbūt jau girdėjai apie CDP – customer data platformas. Rinka jų pilna, nuo gigantų kaip Segment ar mParticle iki mažesnių žaidėjų. Bet šiandien kalbėsime apie Ortto, kurią kai kas dar prisimena kaip Autopilot. Ši australų kompanija padarė įdomų dalyką – sukūrė CDP, kuri ne tik renka ir sujungia duomenis, bet ir leidžia su jais dirbti praktiškai, nereikalaujant dar dešimties papildomų įrankių.

Ortto pozicionuoja save kaip „customer data and marketing automation platform”, ir čia slypi pagrindinis skirtumas nuo tradicinių CDP. Daugelis platformų sutelkia dėmesį į duomenų surinkimą ir saugojimą, palikdamos visą marketing automation dalį kitiems įrankiams. Ortto bando būti viskas viename – nuo event tracking’o iki email kampanijų ir push notification’ų. Ar tai gerai ar blogai? Kaip visada – depends.

Kas iš tikrųjų yra Ortto ir kodėl Autopilot pasikeitė

Pradėkime nuo istorijos. Autopilot buvo gana populiarus marketing automation įrankis, ypač tarp SaaS kompanijų. 2021 metais įvyko rebrandingas į Ortto, ir tai nebuvo tik pavadinimo keitimas. Produktas buvo iš esmės perdirbtas, pridedant daug gilesnę CDP funkcionalumo dalį.

Dabartinis Ortto – tai platforma, kuri leidžia:

  • Rinkti klientų duomenis iš įvairių šaltinių (website, mobile app, backend sistemos)
  • Sujungti visus duomenis į vieną klientų profilį
  • Segmentuoti auditorijas pagal bet kokius kriterijus
  • Kurti automatizuotus marketing workflow’us
  • Siųsti email, SMS, push notification’us
  • Analizuoti rezultatus ir klientų kelionę

Skamba kaip standartinis marketing automation įrankis? Beveik. Bet čia yra vienas svarbus niuansas – Ortto pradeda nuo duomenų, ne nuo kampanijų. Tai CDP, kuri turi marketing automation funkcijas, o ne atvirkščiai. Šis skirtumas gali atrodyti subtilus, bet praktikoje jis keičia viską.

Techninis setup’as: kaip tai veikia po gaubtu

Integruoti Ortto į savo sistemą galima keliais būdais. Pirmiausia – JavaScript SDK, kurį įdedi į savo website. Tai standartinis dalykas, panašus kaip Google Analytics ar Mixpanel tracking. SDK automatiškai pradeda rinkti pageview’us, click’us ir kitus bazinių event’us.

Bet tikroji galia atsiskleidžia, kai pradedi siųsti custom event’us. Ortto turi gana paprastą API:

„`javascript
window.ortto.track(‘product_viewed’, {
product_id: ‘12345’,
product_name: ‘Premium Plan’,
price: 99.99,
currency: ‘USD’
});
„`

Nieko revoliucingo, bet veikia stabiliai. Kas svarbu – Ortto automatiškai sukuria event schema ir leidžia ją redaguoti UI’je. Nereikia iš anksto definuoti visų properties, kaip kai kuriose kitose platformose.

Server-side integracija taip pat paprasta. Jie turi oficialius SDK Python, Ruby, PHP, Node.js. Dokumentacija gana išsami, nors kartais trūksta edge case’ų aprašymų. Pavyzdžiui, kaip elgtis su dideliais batch’ais ar rate limiting’u – tai reikėjo išsiaiškinti trial and error būdu.

Duomenų modelis ir kas jį daro kitokį

Ortto duomenų modelis sukasi apie tris pagrindinius objektus: People, Activities ir Custom Objects. People – tai jūsų kontaktai/klientai. Activities – tai visi event’ai, kuriuos jie atlieka. Custom Objects – tai bet kokie papildomi duomenys, pvz., produktai, užsakymai, subscription’ai.

Kas įdomu – Ortto leidžia kurti relationships tarp šių objektų. Pavyzdžiui, galite susieti Person su keliais Subscription objektais, o kiekvieną Subscription su Product objektu. Tai leidžia kurti labai sudėtingus segmentus ir personalizuotą content’ą.

Praktinis pavyzdys: norite siųsti email’ą visiems klientams, kurių subscription’as baigiasi per 7 dienas, bet tik tiems, kurie turi Premium planą ir neprisijungė paskutines 30 dienų. Su Ortto tai galite padaryti tiesiog UI’je, be jokio SQL ar custom scripting’o.

Duomenų saugojimas – čia Ortto laiko viską savo infrastruktūroje (AWS). Nėra galimybės naudoti savo database ar data warehouse. Tai gali būti deal-breaker didelėms enterprise kompanijoms, kurios nori pilną kontrolę. Bet mažesnėms organizacijoms tai faktiškai privalumas – viena problema mažiau.

Segmentacija ir audience building realybėje

Segmentacijos UI Ortto yra vienas iš stipriausių produkto aspektų. Jie turi vizualų query builder’į, kuris leidžia kombinuoti bet kokius conditions su AND/OR logika. Bet kas tikrai cool – galite matyti real-time, kiek žmonių patenka į jūsų segmentą, kai keičiate parametrus.

Pavyzdžiui, kuriate segmentą „Active trial users”. Pridedate condition’ą: „Signed up in last 14 days”. Matote – 234 žmonės. Pridedate dar vieną: „Logged in at least 3 times”. Skaičius iš karto atsinaujina – 89 žmonės. Pridedate: „Did NOT complete onboarding”. Lieka 23. Viskas vyksta per sekundę, nereikia laukti, kol perskaičiuos.

Ortto taip pat palaiko dynamic segments – jie automatiškai atsinaujina, kai žmonės įeina ar išeina pagal kriterijus. Tai labai patogu automation’ams. Pavyzdžiui, sukuriate journey, kuris automatiškai įtraukia naujus trial user’ius ir siunčia jiems onboarding email’ų seriją.

Vienas trūkumas – kai segmentai tampa labai sudėtingi (daug nested conditions, relationships su custom objects), kartais performance’as pradeda kentėti. Segment’o perskaičiavimas gali užtrukti kelias sekundes, o tai UI’je jaučiasi ne labai smooth.

Marketing automation: journey builder ir kas su juo ne taip

Journey builder – tai Ortto širdis. Vizualus workflow editor’ius, kuriame kuriate customer journeys nuo trigger’io iki conversion’o. Atrodo pažįstamai, jei naudojote Klaviyo, ActiveCampaign ar panašius įrankius.

Trigger’iai gali būti įvairūs: žmogus įeina į segmentą, įvyksta konkretus event’as, ateina tam tikra data, arba net API call’as iš išorės. Paskui galite pridėti actions: siųsti email’ą, SMS’ą, push notification’ą, atnaujinti contact properties, pridėti į kitą segmentą, siųsti webhook’ą.

Kas veikia gerai: email editor’ius yra solid. Turi drag-and-drop builder’į su gana gražiais template’ais. Personalizacija veikia sklandžiai – galite įterpti bet kokius contact properties ar custom object duomenis. A/B testing’as integruotas natūraliai.

Kas veikia ne taip gerai: conditional logic journey’se kartais būna confusing. Pavyzdžiui, norite sukurti branch’ą pagal tai, ar žmogus atidarė email’ą. Pridedate „Wait for email open” step’ą su timeout’u 3 dienos. Bet kas nutinka, jei žmogus atidaro email’ą po 4 dienų? Jis jau išėjo per timeout branch’ą. Dokumentacija šitų edge case’ų nepaaiškina aiškiai.

Dar viena problema – debugging. Kai journey neveikia kaip tikėjotės, gali būti sudėtinga suprasti kodėl. Activity log’as rodo, kas įvyko, bet ne visada kodėl kas nors NEĮVYKO. Pavyzdžiui, kodėl žmogus nepateko į tam tikrą branch’ą – reikia rankiniu būdu tikrinti visus conditions.

Integracijos ir ekosistema

Ortto turi integracijas su populiariausiomis platformomis: Salesforce, HubSpot, Stripe, Shopify, Segment, Zapier ir t.t. Bet čia reikia būti atsargiems – ne visos integracijos yra equally good.

Stripe integracija, pavyzdžiui, veikia puikiai. Automatiškai sinchronizuoja customer’ius, subscription’us, payment’us. Galite kurti segmentus pagal MRR, churn date, payment failures. Viskas ką tikėtumėtės.

Salesforce integracija – čia jau sudėtingiau. Ji veikia, bet sync’as kartais būna lėtas (iki 15 minučių). Ir jei turite custom Salesforce objects, reikės papildomo setup’o. Dokumentacija čia galėtų būti geresnė.

Shopify integracija solid, bet tik jei naudojate standard Shopify setup’ą. Jei turite headless Shopify ar custom checkout’ą, reikės papildomo development’o.

Kas trūksta – tiesioginių integracijų su data warehouse’ais (Snowflake, BigQuery, Redshift). Jei norite eksportuoti duomenis į savo warehouse’ą, reikės naudoti Zapier ar custom API integration’ą. Tai gana didelis trūkumas kompanijoms, kurios nori centralizuoti visus duomenis.

Pricing ir ar tai verta pinigų

Ortto pricing’as bazuojasi ant contacts skaičiaus ir features. Prasideda nuo ~$509/mėnesį už 10,000 contacts (Essential planas). Professional planas su visomis features – apie $1,249/mėnesį už tą patį contacts skaičių.

Palyginus su konkurentais: Klaviyo panašiam contacts skaičiui kainuotų apie $700/mėnesį, bet jie specializuojasi e-commerce. HubSpot Marketing Hub Professional – apie $800/mėnesį, bet jums dar reikės CDP funkcionalumo iš kur nors kitur. Segment (CDP) – nuo $120/mėnesį, bet tai tik duomenų platforma, marketing automation reikės atskirai.

Taigi Ortto pricing’as konkurencingas, jei žiūrite į jį kaip į CDP + marketing automation combo. Bet jei jums reikia tik vieno iš šių dalykų, greičiausiai rasite pigesnių alternatyvų.

Vienas svarbus dalykas – Ortto skaičiuoja contacts, ne tik active contacts. Tai reiškia, jei turite 50,000 contacts savo database, bet tik 10,000 yra active, vis tiek mokėsite už visus 50,000. Kai kurie konkurentai (pvz., ActiveCampaign) skaičiuoja tik active contacts, kas gali būti pigiau.

Kada Ortto turi prasmę ir kada ne

Po kelių mėnesių darbo su Ortto, galiu pasakyti, kad ši platforma turi savo sweet spot’ą. Ji puikiai tinka:

B2B SaaS kompanijoms su 10-500 darbuotojų. Jūs turite pakankamai sudėtingą product’ą, kad reikėtų tikros CDP, bet neturite resursų integruoti ir prižiūrėti 5 skirtingus įrankius. Ortto duoda jums 80% to, ko reikia, vienoje vietoje.

Kompanijoms, kurios nori greitai eksperimentuoti. Setup’as paprastas, galite per dieną paleisti naują campaign’ą ar journey. Nereikia laukti, kol data team’as padarys naują segment’ą SQL’e.

Organizacijoms su technical marketing team’u. Jei jūsų marketers supranta API, event’us, data models – Ortto bus kaip žaidimų aikštelė. Bet jei jūsų team’as labai non-technical, kai kurie dalykai gali būti per sudėtingi.

Kada Ortto NĖRA geras pasirinkimas:

Jei jums reikia enterprise-level customization. Ortto yra opinionated platform – ji turi savo būdą, kaip dalykai turėtų veikti. Jei jums reikia labai specifinio setup’o ar full control over data infrastructure, žiūrėkite į Segment ar mParticle.

Jei jūsų pagrindinis use case yra e-commerce. Klaviyo ar Omnisend bus geresni pasirinkimai – jie turi daug daugiau e-commerce specific features.

Jei turite labai didelę contacts bazę (1M+). Pricing’as tampa labai brangus, ir performance’as gali pradėti kentėti. Tokiu atveju žiūrėkite į enterprise CDP sprendimus.

Praktinis patarimas: jei svarstote Ortto, paprašykite trial’o ir setup’inkite vieną pilną customer journey nuo signup’o iki conversion’o. Tai duos jums gerą supratimą, ar platforma tinka jūsų use case’ui. Nedarykit klaidos bandydami įvertinti tik pagal feature list’ą ar demo – tikrasis test’as yra implementation.

Dar vienas dalykas – Ortto support’as yra gana responsive, bet jie yra Australijoje, tai jei esate Europoje ar US, time zone’ai gali būti challenging. Dokumentacija padeda, bet kaip minėjau, kartais trūksta detalių.

Apskritai, Ortto yra solid middle-market CDP su marketing automation. Ji nėra tobula, bet mažai kas yra. Jei jūsų use case’as atitinka jų sweet spot’ą, tai gali būti puikus pasirinkimas, kuris sutaupys jums laiko ir pinigų palyginus su kelių įrankių stack’u. Bet jei jūsų poreikiai yra labai specifiniai arba labai paprasti, greičiausiai rasite geresnių alternatyvų.

Gatsby static site generatoriaus panaudojimas

by adminin Hostingas / svetainių talpinimasLeave a Comment on Gatsby static site generatoriaus panaudojimas

Kodėl Gatsby vis dar aktualus 2024-aisiais

Kai prieš kelerius metus pirmą kartą išgirdau apie Gatsby, atrodė, kad tai dar vienas React framework’as, kuris greitai dings iš radaro. Bet štai – jis ne tik neišnyko, bet ir toliau lieka vienu iš populiariausių static site generatorių. Taip, žinau, dabar visi kalba apie Next.js, Astro ir kitus naujokus, bet Gatsby turi savo nišą ir ją užpildo puikiai.

Gatsby iš esmės yra React-based framework’as, kuris generuoja statinius HTML failus. Skamba paprasta, bet po gaubtu slypi GraphQL duomenų sluoksnis, galingas plugin’ų ekosistema ir optimizacijos, kurias rankiniu būdu įgyvendinti užtruktų amžinybę. Jei kada nors kūrėte portfolio, blog’ą ar dokumentacijos puslapį, tikrai susidūrėte su dilema: WordPress? Custom sprendimas? SPA? Gatsby čia siūlo kompromisą tarp greičio, kūrėjo patirties ir galutinio rezultato.

Kas man patinka labiausiai – tai kad Gatsby neprievartauja. Galite pradėti nuo paprasto starter’io ir palaipsniui pridėti sudėtingumo. O kai reikia SEO, greičio ar prieinamumo – visa tai jau įkepinta į framework’ą.

Kaip Gatsby veikia po gaubtu

Pirmą kartą paleidus gatsby develop, gali atrodyti, kad vyksta kažkas panašaus į Next.js. Bet skirtumas fundamentalus. Gatsby build metu iš tikrųjų generuoja visus galimus HTML failus iš anksto. Tai reiškia, kad jūsų serveris (ar CDN) tiesiog atiduoda gatavus failus – jokio server-side rendering’o, jokių duomenų bazių užklausų.

Štai kaip tai veikia praktiškai: jūs rašote React komponentus, apibrėžiate duomenų šaltinius (Markdown failai, CMS, API), o Gatsby build proceso metu:

  • Surenka visus duomenis per GraphQL
  • Paleidžia React komponentus su tais duomenimis
  • Sugeneruoja statinius HTML failus kiekvienam route’ui
  • Optimizuoja paveikslėlius, CSS, JavaScript
  • Sukuria prefetch strategijas greičiau navigacijai

Rezultatas? Pirmas puslapio įkėlimas greitesnis nei daugelio SPA, o vėliau navigacija tarp puslapių vyksta beveik akimirksniu, nes Gatsby po gaubtu naudoja React Router ir prefetch’ina kitus puslapius.

Vienas dalykas, kuris man asmeniškai kėlė klausimų pradžioje – kodėl GraphQL? Atrodo kaip overkill’as paprastam blog’ui. Bet kai pradedi dirbti su keliais duomenų šaltiniais (pvz., Markdown failai + Contentful + REST API), GraphQL sluoksnis tampa išganymu. Visi duomenys prieinami per vieną vientisą API, su type safety ir autocomplete.

Praktinis projekto setup’as nuo nulio

Gerai, užtenka teorijos. Sukurkime realų projektą. Tarkime, norime padaryti tech blog’ą su straipsniais Markdown formatu ir dinamiškai generuojamais puslapiais.

Pradedame standartiškai:

npm init gatsby

CLI paklaus kelių klausimų – pasirinkite TypeScript (jei esate normalus žmogus), styling sprendimą (aš dažniausiai einu su styled-components arba CSS modules), ir ar norite CMS integracijos. Pradžiai galite praleisti CMS – pridėsime vėliau jei reikės.

Po kelių minučių turėsite veikiantį Gatsby projektą. Struktūra bus maždaug tokia:


src/
pages/ # Automatiškai tampa route'ais
components/ # React komponentai
templates/ # Template'ai dinaminiams puslapiams
gatsby-config.js # Pagrindinis config'as
gatsby-node.js # Build-time logika

Dabar įdomi dalis – pridėkime galimybę skaityti Markdown failus. Tam reikės dviejų plugin’ų:

npm install gatsby-source-filesystem gatsby-transformer-remark

gatsby-config.js faile sukonfiguruojame:


plugins: [
{
resolve: 'gatsby-source-filesystem',
options: {
name: 'posts',
path: `${__dirname}/content/posts`,
},
},
'gatsby-transformer-remark',
]

Dabar sukurkite content/posts/ direktoriją ir įmeskite kelis Markdown failus su frontmatter:


---
title: "Mano pirmas Gatsby straipsnis"
date: "2024-01-15"
slug: "pirmas-straipsnis"
---

Čia eina turinys...

GraphQL užklausos ir duomenų gavimas

Vienas iš Gatsby privalumų – GraphiQL playground, prieinamas http://localhost:8000/___graphql. Čia galite eksperimentuoti su užklausomis realiu laiku.

Pavyzdžiui, norint gauti visus blog post’us:


query {
allMarkdownRemark(sort: {frontmatter: {date: DESC}}) {
nodes {
frontmatter {
title
date
slug
}
excerpt
}
}
}

Šią užklausą galite naudoti tiesiog React komponente su useStaticQuery hook’u arba per page query. Skirtumas – useStaticQuery negali priimti kintamųjų, tinka tik statinėms užklausoms.

Praktinis patarimas: pradžioje GraphQL sintaksė gali atrodyti keista, ypač jei ateinat iš REST pasaulio. Bet pasitikėkite – po savaitės jau rašysite užklausas neatidarę dokumentacijos. O autocomplete IDE tikrai padeda.

Dinaminis puslapių generavimas

Gerai, turime Markdown failus, GraphQL užklausas veikia. Bet kaip sukurti atskirą puslapį kiekvienam straipsniui? Čia ateina gatsby-node.js.

Šis failas leidžia hook’intis į Gatsby build procesą. Naudosime createPages API:


exports.createPages = async ({ graphql, actions }) => {
const { createPage } = actions

const result = await graphql(`
query {
allMarkdownRemark {
nodes {
frontmatter {
slug
}
}
}
}
`)

result.data.allMarkdownRemark.nodes.forEach(node => {
createPage({
path: `/blog/${node.frontmatter.slug}`,
component: path.resolve('./src/templates/blog-post.js'),
context: {
slug: node.frontmatter.slug,
},
})
})
}

Dabar sukurkite src/templates/blog-post.js template’ą:


export const query = graphql`
query($slug: String!) {
markdownRemark(frontmatter: {slug: {eq: $slug}}) {
html
frontmatter {
title
date
}
}
}
`

const BlogPost = ({ data }) => {
const post = data.markdownRemark
return (

{post.frontmatter.title}

)
}

Atkreipkite dėmesį – GraphQL užklausoje naudojame $slug kintamąjį, kuris ateina iš context objecto createPage funkcijoje.

Paveikslėlių optimizacija ir gatsby-plugin-image

Jei dirbate su bet kokiu content-heavy projektu, paveikslėliai bus jūsų didžiausia problema. Gatsby turi puikų sprendimą – gatsby-plugin-image.

Šis plugin’as automatiškai:

  • Generuoja skirtingų dydžių versijas
  • Konvertuoja į WebP/AVIF formatą
  • Prideda lazy loading
  • Sukuria blur-up placeholder’ius
  • Optimizuoja pagal viewport dydį

Naudojimas paprastas:


import { StaticImage } from 'gatsby-plugin-image'


Jei paveikslėliai ateina iš GraphQL (pvz., iš Markdown frontmatter), naudokite GatsbyImage komponentą su dynamic image data.

Vienas dalykas, kuris gali suklaidinti – StaticImage reikalauja, kad src būtų statinis string’as, ne kintamasis. Tai dėl to, kad Gatsby build metu turi žinoti, kuriuos paveikslėlius optimizuoti. Jei reikia dinamiškumo, naudokite gatsby-source-filesystem su GraphQL.

Plugin’ų ekosistema ir dažniausios integracijos

Gatsby stiprybė – plugin’ai. Yra jų šimtai, ir daugelis išsprendžia problemas, su kuriomis susidurtumėte bet kuriame projekte.

Štai mano asmeninis „must-have” sąrašas:

gatsby-plugin-manifest – generuoja web app manifest’ą, prideda favicon’us, leidžia padaryti PWA. Setup’as trivialus, rezultatas – profesionaliau atrodantis projektas.

gatsby-plugin-sitemap – automatiškai generuoja sitemap.xml. Jei rūpi SEO (o turėtų), tai no-brainer.

gatsby-plugin-google-gtag – Google Analytics integracija. Yra ir kitų analytics sprendimų, bet šis veikia iš dėžės.

gatsby-plugin-feed – RSS feed’as. Taip, RSS dar gyvas, ir jei darote blog’ą, žmonės tikrai naudoja.

gatsby-source-contentful (arba Sanity, Strapi, kt.) – jei dirbate su headless CMS. Gatsby puikiai integruojasi su visais pagrindiniais CMS sprendimais.

Vienas patarimas dėl plugin’ų – neskubėkite pridėti visko iš karto. Pradėkite su minimaliu setup’u ir pridėkite funkcionalumą pagal poreikį. Kiekvienas plugin’as prideda build time, o kai projektas auga, tai tampa jaučiama.

Performance optimizacijos ir deployment

Gatsby iš dėžės duoda gerą performance, bet yra keletas dalykų, kuriuos galite padaryti dar geriau.

Pirma – code splitting. Gatsby tai daro automatiškai, bet galite padėti su dynamic import’ais:


const HeavyComponent = React.lazy(() => import('./HeavyComponent'))

Antra – prefetching strategija. Gatsby default’u prefetch’ina visus link’us, kurie matomi viewport’e. Tai super greita navigacija, bet jei turite šimtus link’ų puslapyje, gali būti per daug. Galite kontroliuoti per gatsby-config.js:


module.exports = {
flags: {
FAST_DEV: true,
PRESERVE_FILE_DOWNLOAD_CACHE: true,
},
}

Trečia – incremental builds. Jei naudojate Gatsby Cloud arba Netlify, galite enable’inti incremental builds, kurie rebuild’ina tik pasikeitusias dalis. Tai gali sumažinti build laiką nuo 10 minučių iki 30 sekundžių.

Dėl deployment’o – Gatsby puikiai veikia su:

  • Netlify (mano asmeninis favoritas, turi puikią Gatsby integraciją)
  • Vercel (taip pat puiku, nors labiau orientuota į Next.js)
  • Gatsby Cloud (oficialus sprendimas, bet mokamas)
  • GitHub Pages (nemokamas, bet ribotesnis)
  • AWS S3 + CloudFront (jei norite full control)

Netlify setup’as paprastas kaip du kartus du – sujunkite GitHub repo, nurodykite build komandą (gatsby build), ir publish direktoriją (public/). Viskas. Kiekvienas push į main branch’ą automatiškai deploy’ins naują versiją.

Ką daryti kai projektas auga ir tampa lėtas

Štai kur Gatsby kartais gauna kritikos – dideli projektai gali turėti ilgus build laikus. Jei turite tūkstančius puslapių, build’as gali trukti 15-30 minučių ar net ilgiau.

Keletas strategijų kaip su tuo kovoti:

Deferred Static Generation (DSG) – naujesnis Gatsby feature’as, leidžiantis atidėti kai kurių puslapių generavimą iki pirmo request’o. Puikiai tinka puslapiams, kurie retai lankami:


export async function config() {
return {
defer: true
}
}

Partial Hydration – ne visi komponentai turi būti interactive. Galite naudoti gatsby-plugin-no-javascript tam tikroms dalims, jei jos tik statinės.

Build cache’inimas – įsitikinkite, kad CI/CD sistema cache’ina .cache ir public direktorijas tarp build’ų.

Duomenų šaltinių optimizacija – jei traukiate duomenis iš external API, įsitikinkite, kad naudojate pagination, filtravimą, ir traukiate tik tai ko reikia.

Vienas realus pavyzdys iš praktikos – dirbau projekte su ~5000 blog post’ų. Build laikas buvo 25 minutės. Po optimizacijų (DSG, geresnės GraphQL užklausos, incremental builds) nukrito iki 3 minučių normaliam update’ui ir ~10 minučių full rebuild’ui.

Ar Gatsby vis dar verta mokytis dabar

Tiesą sakant, Gatsby ekosistema šiek tiek sulėtėjo pastaraisiais metais. Next.js paėmė daug dėmesio, Astro atėjo su naujomis idėjomis, Remix irgi žaidžia toje pačioje aikštelėje. Bet Gatsby vis dar turi savo vietą.

Jei darote content-heavy projektą, kur SEO yra kritinis, ir nereikia daug server-side logikos – Gatsby puikus pasirinkimas. Plugin’ų ekosistema, paveikslėlių optimizacija, ir developer experience vis dar top tier. Dokumentacija išsami, community aktyvus (nors ne toks kaip Next.js), ir yra daugybė realių production projektų ant Gatsby.

Kita vertus, jei darote aplikaciją su daug dinamikos, authentication, real-time features – galbūt Next.js ar Remix būtų geresnis pasirinkimas. Gatsby stipriausia statinio content’o srityje.

Mano asmeninė nuomonė – Gatsby vis dar verta mokytis, ypač jei jau mokate React. Daugelis konceptų (component architecture, GraphQL, build-time optimization) persikeliami į kitus framework’us. O jei kada nors reikės padaryti greitą, SEO-friendly website’ą – Gatsby leis tai padaryti per savaitgalį, ne mėnesį.

Taigi, ar verta? Priklauso nuo use case’o. Bet jei skaitote šį straipsnį, tikėtina kad jūsų use case’as Gatsby teritorijoje. Tad drąsiai eksperimentuokite, pradėkite nuo mažo projekto, ir pamatysite ar jums prie širdies. Worst case – išmoksite React ir GraphQL geriau. Best case – turėsite naują įrankį toolbox’e, kuris išspręs realias problemas.

CloudCannon Git-based CMS Jekyll ir Hugo

by adminin Hostingas / svetainių talpinimasLeave a Comment on CloudCannon Git-based CMS Jekyll ir Hugo

Kas yra CloudCannon ir kam jis skirtas

Jei dirbate su statiniais svetainių generatoriais, turbūt jau girdėjote apie CloudCannon. Tai Git-pagrįsta turinio valdymo sistema (CMS), kuri puikiai integruojasi su Jekyll ir Hugo – dviem populiariausiomis statinių svetainių generavimo platformomis. Skirtingai nei tradicinės CMS, tokios kaip WordPress ar Drupal, CloudCannon leidžia išlaikyti visus statinių svetainių privalumus, tuo pačiu suteikdama patogią sąsają turinio redagavimui.

Pagrindinis CloudCannon pranašumas – tai tiltas tarp kūrėjų ir turinio kūrėjų. Kūrėjai gali toliau dirbti su savo mėgstamomis technologijomis, naudoti Git workflow’ą, o turinio autoriai gauna intuityvią vizualinę sąsają, kur gali redaguoti tekstus, keisti nuotraukas ir valdyti svetainės turinį be jokių techninių žinių. Nereikia mokytis Markdown sintaksės ar suprasti, kaip veikia Git komandos.

Sistema veikia tiesiogiai su jūsų Git repozitorija – GitHub, GitLab ar Bitbucket. Kai redaktorius atlieka pakeitimus per CloudCannon sąsają, sistema automatiškai sukuria commit’ą ir atnaujina jūsų repozitoriją. Tai reiškia, kad viskas lieka versijuojama, galite grįžti prie ankstesnių versijų, o deployment’as vyksta automatiškai.

Jekyll integracija: kaip tai veikia praktikoje

Jekyll yra vienas seniausių ir populiariausių statinių svetainių generatorių, ypač mėgstamas GitHub Pages naudotojų. CloudCannon su Jekyll dirba itin sklandžiai, nes platforma iš pradžių buvo kuriama būtent šiam generatoriui palaikyti.

Kai prijungiate Jekyll projektą prie CloudCannon, sistema automatiškai atpažįsta jūsų projekto struktūrą. Ji identifikuoja collections, data failus, layouts ir kitus Jekyll komponentus. Tai reiškia, kad jums nereikia nieko specialiai konfigūruoti – sistema pati supranta, kaip jūsų svetainė sukonstruota.

Vienas įdomiausių dalykų – vizualus redagavimas. CloudCannon leidžia redaguoti turinį tiesiogiai naršyklėje, matant realų rezultatą. Jei turite tinkamai sukonfigūruotus editable regions, turinio kūrėjai gali tiesiog spragtelėti ant teksto ir jį keisti, tarsi dirbtų su WordPress ar kita tradicine CMS. Tai ypač patogu klientams, kurie nenori mokytis techninių dalykų.

Front matter redagavimas taip pat yra labai intuityvus. Vietoj to, kad redaktorius turėtų rašyti YAML sintaksę rankomis, CloudCannon generuoja formas su atitinkamais laukais. Galite sukonfigūruoti, kokie laukai turėtų būti rodomi, kokio tipo jie yra (tekstas, data, pasirinkimas iš sąrašo), net pridėti validacijas. Pavyzdžiui, jei turite blog post’ą su kategorijomis, galite sukurti dropdown meniu su galimomis kategorijomis, užuot leidę redaktoriui rašyti jas rankomis.

Hugo palaikymas ir jo ypatumai

Hugo pastaraisiais metais tapo itin populiarus dėl savo greičio – tai greičiausias statinis generatorius rinkoje. CloudCannon pradėjo palaikyti Hugo vėliau nei Jekyll, bet dabar integracija yra labai brandi ir funkcionaliai turtinga.

Vienas iš Hugo privalumų – jo lankstumas ir galimybė dirbti su dideliais projektais. Jei turite svetainę su tūkstančiais puslapių, Hugo sugeneruos ją per sekundes, o ne minutes. CloudCannon šį pranašumą išlaiko – preview’ai generuojami greitai, o deployment’as vyksta žaibiškai.

Hugo naudoja šiek tiek kitokią struktūrą nei Jekyll. Vietoj collections, Hugo turi content types ir sections. CloudCannon puikiai su tuo susidoroja ir automatiškai atpažįsta jūsų Hugo projekto struktūrą. Archetypes, shortcodes, taxonomies – visa tai palaikoma ir gali būti integruota į redagavimo sąsają.

Vienas dalykas, kurį pastebėjau dirbdamas su Hugo CloudCannon platformoje – tai shortcode’ų palaikymas. Hugo shortcode’ai yra galingas įrankis, leidžiantis įterpti sudėtingą funkcionalumą į turinį. CloudCannon leidžia sukurti snippet’us, kurie atitinka jūsų shortcode’us, ir redaktoriai gali juos įterpti per vizualinę sąsają, užpildydami paprastas formas. Tai labai patogu, kai turite, pavyzdžiui, sudėtingą galerijos shortcode’ą su daugybe parametrų.

Konfigūravimas ir pradžios žingsniai

Pradėti naudoti CloudCannon nėra sudėtinga, bet yra keletas dalykų, kuriuos verta žinoti iš anksto. Pirmiausia, jums reikia turėti veikiančią Jekyll arba Hugo svetainę Git repozitorijoje. Jei dar neturite, galite pradėti nuo vieno iš CloudCannon template’ų – jie turi gana gerą pasirinkimą.

Prijungus repozitoriją, CloudCannon automatiškai bandys build’inti jūsų svetainę. Jei naudojate standartinę konfigūraciją, viskas turėtų veikti iš karto. Bet jei turite specifinių reikalavimų – custom plugins Jekyll atveju arba specifinę Hugo versiją – turėsite tai nurodyti konfigūracijos faile.

CloudCannon konfigūracija vykdoma per cloudcannon.config.yml failą projekto šakniniame kataloge. Čia galite apibrėžti, kaip turėtų atrodyti redagavimo sąsaja, kokie laukai turėtų būti rodomi, kaip turėtų veikti navigacija ir daug kitų dalykų. Pradžioje gali atrodyti, kad reikia daug konfigūruoti, bet iš tikrųjų daugelis dalykų veikia automatiškai, o konfigūracija reikalinga tik specifiniams poreikiams.

Vienas svarbus dalykas – inputs konfigūracija. Tai leidžia apibrėžti, kaip turėtų atrodyti front matter laukai redagavimo sąsajoje. Pavyzdžiui, jei turite datą, galite nurodyti, kad tai turėtų būti date picker. Jei turite nuorodą į kitą puslapį, galite sukonfigūruoti, kad tai būtų dropdown su visais galimais puslapiais. Tai labai pagerina redaktorių patirtį.

Vizualinis redagavimas ir jo galimybės

Viena iš stipriausių CloudCannon pusių – vizualinis redagavimas. Tai ne tik WYSIWYG editorius tekstui – tai galimybė redaguoti turinį tiesiogiai svetainės kontekste, matant, kaip viskas atrodys galutinėje svetainėje.

Kad tai veiktų, jums reikia apibrėžti editable regions savo template’uose. Jekyll atveju tai daroma naudojant specialius class’us arba data atributus. Hugo atveju principas panašus. Kai redaktorius atidaro puslapį vizualiniame režime, jis gali spragtelėti ant bet kurio editable regiono ir pradėti redaguoti.

Vizualinis editorius palaiko įvairius turinio tipus. Galite redaguoti paprastą tekstą, antraštes, sąrašus, nuorodas. Galite įterpti nuotraukas, kurios automatiškai įkeliamos į jūsų asset management sistemą. Galite net pridėti naujus komponentus, jei turite sukonfigūravę structures – tai leidžia apibrėžti pasikartojančias turinio struktūras, kurias redaktoriai gali pridėti ar pašalinti.

Pavyzdžiui, jei turite landing page su skirtingomis sekcijomis (hero, features, testimonials, CTA), galite sukonfigūruoti kiekvieną sekciją kaip atskirą structure. Redaktorius gali pridėti naują features sekciją, užpildyti jos laukus, perkelti ją į kitą vietą – viskas vyksta vizualioje sąsajoje, be jokio kodo rašymo.

Asset management ir optimizavimas

Dirbant su bet kokia svetaine, vienas didžiausių iššūkių – asset’ų valdymas. Nuotraukos, dokumentai, video failai – visa tai reikia kažkur laikyti ir efektyviai valdyti. CloudCannon turi integruotą asset management sistemą, kuri šį procesą daro gana paprastą.

Kai įkeliate nuotrauką per CloudCannon sąsają, ji automatiškai patalpinama į jūsų projekto assets katalogą ir commit’inama į Git. Tai reiškia, kad visi asset’ai yra versijuojami kartu su kodu ir turiniu. Kai kuriems tai gali atrodyti kaip trūkumas (Git repozitorijos dydis auga), bet praktikoje tai suteikia gerą kontrolę ir paprastumą.

CloudCannon taip pat siūlo automatinį nuotraukų optimizavimą. Galite sukonfigūruoti, kad visos įkeliamos nuotraukos būtų automatiškai sumažinamos, konvertuojamos į WebP formatą, generuojamos skirtingų dydžių versijos responsive dizainui. Tai labai patogu, nes redaktoriams nereikia rūpintis technine puse – jie tiesiog įkelia nuotrauką, o sistema pasirūpina optimizavimu.

Vienas įdomus feature’as – DAM (Digital Asset Management) integracija. Jei naudojate išorinę DAM sistemą, tokią kaip Cloudinary ar imgix, galite ją integruoti su CloudCannon. Tai leidžia laikyti asset’us atskirai nuo Git repozitorijos, bet vis tiek valdyti juos per CloudCannon sąsają.

Deployment ir hosting galimybės

CloudCannon ne tik CMS, bet ir hosting platforma. Kai build’as užbaigiamas, svetainė automatiškai deploy’inama į CloudCannon infrastruktūrą. Tai global CDN, todėl jūsų svetainė bus greita visame pasaulyje.

Bet jei norite naudoti kitą hosting’ą, tai taip pat įmanoma. CloudCannon palaiko deployment’ą į AWS S3, Netlify, Vercel, GitHub Pages ir kitas platformas. Galite sukonfigūruoti, kad po kiekvieno sėkmingo build’o svetainė būtų automatiškai deploy’inama į jūsų pasirinktą platformą.

Vienas dalykas, kurį vertinu CloudCannon – tai preview deployment’ai. Kai redaktorius daro pakeitimus, jis gali pamatyti preview prieš publikuojant. Tai atskirtas environment’as, kur galite patikrinti, kaip viskas atrodo, prieš commit’indami pakeitimus į production branch’ą. Tai labai patogu didesniuose projektuose, kur turite approval workflow’ą.

CloudCannon taip pat palaiko branch’ų valdymą. Galite turėti skirtingus branch’us skirtingiems tikslams – development, staging, production. Kiekvienas branch’as gali turėti savo preview URL, ir galite lengvai switch’intis tarp jų. Tai leidžia implementuoti sudėtingus workflow’us, kur pakeitimai pereina per kelis approval stage’us prieš patenkant į production.

Komandinis darbas ir workflow valdymas

Didesniuose projektuose svarbu turėti gerą komandinio darbo organizavimą. CloudCannon siūlo įvairius įrankius tam palengvinti. Pirmiausia – vaidmenų valdymas. Galite apibrėžti skirtingus vaidmenis su skirtingomis teisėmis: administratoriai, redaktoriai, peržiūrėtojai. Kiekvienas vaidmuo gali turėti prieigą tik prie tam tikrų funkcijų.

Pavyzdžiui, redaktoriai gali redaguoti turinį, bet negali keisti svetainės konfigūracijos ar template’ų. Peržiūrėtojai gali tik žiūrėti turinį, bet negali jo keisti. Tai labai svarbu, kai dirbate su klientais ar turite didelę komandą su skirtingais atsakomybės lygiais.

CloudCannon taip pat palaiko approval workflow’us. Galite sukonfigūruoti, kad pakeitimai turėtų būti patvirtinti prieš publikuojant. Kai redaktorius padaro pakeitimus, jie patenka į review stage’ą, ir tik po patvirtinimo yra commit’inami į production branch’ą. Tai ypač naudinga reguliuojamose industrijose ar kai turite griežtus content quality reikalavimus.

Activity log’as leidžia sekti, kas, kada ir ką pakeitė. Tai naudinga audit’ui ir problemų sprendimui. Jei kas nors sugenda, galite greitai pamatyti, kas darė pakeitimus ir grįžti prie ankstesnės versijos. Kadangi viskas vyksta per Git, turite pilną istoriją su commit message’ais.

Ką reikia žinoti prieš pradedant ir kaip išspausti maksimumą

CloudCannon yra galingas įrankis, bet kaip ir bet kuri platforma, jis turi savo ypatumų ir apribojimų. Pirmiausia – kaina. Nemokamas planas yra gana ribotas ir tinka tik mažiems projektams ar testavimui. Rimtiems projektams reikės mokamo plano, o jei turite didelę komandą ar daug svetainių, kaina gali būti gana aukšta.

Antra – learning curve. Nors CloudCannon stengiasi būti intuityvus, pilnai išnaudoti visas galimybes reikia laiko. Ypač konfigūracija gali būti sudėtinga pradžioje. Verta skirti laiko dokumentacijai ir eksperimentavimui su test projektu prieš pradedant dirbti su production svetaine.

Trečia – Jekyll plugins apribojimai. Jei naudojate custom Jekyll plugins, kurie nėra whitelist’e, turėsite problemas. CloudCannon palaiko tik safe plugins, panašiai kaip GitHub Pages. Jei jūsų svetainė remiasi custom plugins, gali tekti juos przepisyti arba ieškoti alternatyvų. Hugo šiuo atžvilgiu yra lankstesnis, nes viskas yra built-in.

Dar vienas patarimas – investuokite laiko į gerą content modeling’ą. Gerai apgalvotas content model’is palengvins redaktoriams darbą ir sumažins klaidų tikimybę. Naudokite structures sudėtingesnėms sekcijoms, apibrėžkite aiškius input types, pridėkite help text’us. Tai gali atrodyti kaip papildomas darbas pradžioje, bet atsipirks vėliau.

Dėl performance – nors CloudCannon hosting’as yra greitas, jei turite labai didelę svetainę ar didelį traffic’ą, galbūt verta apsvarstyti custom hosting sprendimą. CloudCannon gali deploy’inti į bet kurią platformą, todėl galite naudoti AWS CloudFront ar Cloudflare su custom konfigūracija, jei reikia specifinių optimizacijų.

Galiausiai – backup strategija. Nors Git pats savaime yra versijų kontrolės sistema, verta turėti papildomus backup’us. CloudCannon leidžia eksportuoti visą svetainę, tad periodiškai darykite backup’us į atskirą vietą. Taip pat įsitikinkite, kad jūsų Git repozitorija yra saugiai laikoma ir turite prieigą prie jos nepriklausomai nuo CloudCannon.

Sistema tikrai verta dėmesio, jei ieškote būdo sujungti statinių svetainių privalumus su patogia turinio valdymo sąsaja. Ji geriausiai tinka agentūroms, kurios kuria svetaines klientams ir nori suteikti jiems paprastą redagavimo įrankį, išlaikant techninę kontrolę. Taip pat puikiai tinka vidutinio dydžio įmonėms, kurios nori greitų, saugių svetainių be tradicinių CMS komplikacijų. Tiesiog būkite pasirengę skirti laiko pradinei konfigūracijai ir mokymui – rezultatas bus vertas pastangų.

„Sendinblue” (Brevo) platformos funkcionalumas

by adminin E-komercijaLeave a Comment on „Sendinblue” (Brevo) platformos funkcionalumas

Kas yra Brevo ir kodėl jis verta dėmesio

Jei dar nežinote, „Sendinblue” neseniai persivadino į „Brevo” – tikriausiai norėdami skambėti šiuolaikiškiau ir tarptautiškiau. Bet pavadinimas čia mažiausiai svarbu. Ši platforma jau seniai išaugo iš paprasto el. pašto siuntimo įrankio į visavertę marketingo automatizavimo sistemą, kuri gali konkuruoti su tokiais gigantais kaip „Mailchimp” ar „HubSpot”.

Pradėjusi kaip prancūzų startuolis, Brevo dabar aptarnauja šimtus tūkstančių klientų visame pasaulyje. Kas įdomiausia – jie sugebėjo išlaikyti gana patrauklią kainų politiką, ypač palyginus su konkurentais. Tai viena iš priežasčių, kodėl daugelis smulkių ir vidutinių įmonių renkasi būtent šią platformą.

Platforma orientuota į tai, kad net ir techniškai nepatyrę vartotojai galėtų susikurti sudėtingas marketingo kampanijas. Tačiau kartu ji turi pakankamai gilių funkcijų, kad patenkintų ir reiklesnių IT specialistų poreikius. API dokumentacija gana išsami, integracijų pasirinkimas platus, o automatizavimo galimybės leidžia sukurti tikrai sofistikuotus darbo srautus.

El. pašto kampanijos ir šablonų kūrimas

Pradėkime nuo pagrindų – el. pašto kampanijų. Brevo redaktorius pastatytas ant „drag-and-drop” principo, kas reiškia, kad galite tiesiog tempti elementus į laiško maketą. Skamba banaliai? Galbūt, bet įgyvendinimas čia tikrai solidus. Redaktorius reaguoja greitai, elementai neprašoka iš vietos, o responsive dizainas veikia kaip reikiant.

Šablonų biblioteka nėra milžiniška, bet kokybė čia svarbesnė už kiekį. Yra kelios dešimtys paruoštų šablonų įvairioms industrijoms – nuo e-komercijos iki B2B paslaugų. Kas svarbiausia – šie šablonai tikrai atrodo šiuolaikiškai, ne kaip 2010-ųjų reliktai.

Jei esate kūrybingesnis arba turite specifinių reikalavimų, galite importuoti savo HTML šabloną. Čia Brevo neriboja – galite naudoti bet kokį validų HTML kodą. Vienintelis dalykas, kurį pastebėjau – kartais platformos inline CSS konvertavimas gali šiek tiek pakeisti jūsų originalų stilių, todėl verta patikrinti preview režime prieš siunčiant.

Personalizavimo galimybės gana išplėstos. Galite naudoti ne tik paprastus kintamuosius kaip vardas ar pavardė, bet ir kurti sudėtingas sąlygas. Pavyzdžiui, rodyti skirtingą turinį priklausomai nuo prenumeratoriaus lokacijos, pirkimo istorijos ar bet kokio kito parametro, kurį turite savo duomenų bazėje.

SMS ir WhatsApp integracija

Štai čia Brevo tikrai išsiskiria iš minios. Daugelis konkurentų vis dar koncentruojasi tik į el. paštą, bet Brevo nuo pat pradžių siūlė SMS funkcionalumą. Dabar jie pridėjo ir WhatsApp Business API palaikymą, kas tampa vis aktualesniu daugelyje rinkų.

SMS kampanijos kuriamos panašiai kaip ir el. laiškų – tas pats intuityvus interfeisas, personalizavimo galimybės, segmentavimas. Kaina priklauso nuo šalies, į kurią siunčiate, bet paprastai ji konkurencinga. Lietuvoje SMS kaina svyruoja apie 0.04-0.06 EUR už žinutę, kas yra visai priimtina.

WhatsApp integracija veikia per oficialią Meta Business API, kas reiškia, kad jūsų žinutės bus siųstos iš patvirtinto verslo numerio. Tai suteikia patikimumo ir leidžia naudoti visus WhatsApp Business funkcionalumus – nuo greitųjų atsakymų iki interaktyvių mygtukų. Tiesa, WhatsApp API nėra pigus malonumas – Meta ima savo mokesčius, o Brevo prideda savo markup. Bet jei jūsų auditorija aktyviai naudoja WhatsApp, investicija gali atsipirkti.

Vienas iš praktiškiausių dalykų – galite kurti multi-channel kampanijas. Pavyzdžiui, pradėti el. paštu, o jei žmogus neatidarė per 48 valandas – siųsti SMS priminimą. Arba siųsti WhatsApp žinutę tiems, kurie davė sutikimą, o kitiems – el. laišką. Tokia logika kuriama per automatizavimo įrankius, apie kuriuos pakalbėsime toliau.

Marketing automation ir workflow kūrimas

Čia prasideda tikroji magija. Brevo automatizavimo įrankis leidžia kurti sudėtingus scenarijus be jokio kodavimo. Vizualus redaktorius rodo visą jūsų workflow kaip blokų schemą, kur kiekvienas blokas gali būti veiksmas, sąlyga ar laukimas.

Galite kurti klasikinius scenarijus kaip welcome serijos, apleistų krepšelių priminimus, gimtadienių sveikinimus. Bet galite eiti ir daug toliau – pavyzdžiui, sukurti lead nurturing seką, kuri keičiasi priklausomai nuo to, kokius el. laiškus žmogus atidaro, kokius puslapius aplanko jūsų svetainėje, kokius produktus žiūri.

Trigger’ių pasirinkimas tikrai įspūdingas:

  • Kontakto sukūrimas ar atnaujinimas
  • El. laiško atidarymas ar paspaudimas
  • Svetainės lankymas (per tracking script)
  • Webhook’ai iš išorinių sistemų
  • Datos (gimtadienis, prenumeratos pabaiga ir pan.)
  • Sąrašo pasikeitimas

Workflow gali turėti kelis šakojimosi taškus su if/else logika. Pavyzdžiui, jei kontaktas atidarė el. laišką ir paspaudė ant konkretaus produkto nuorodos – siųsti vieną sekų, jei neatidarė – kitą. Galite pridėti laukimo periodus (valandos, dienos, savaitės), tikrinti papildomas sąlygas bet kuriame taške.

Kas man asmeniškai patinka – galite testuoti workflow su konkrečiu kontaktu prieš paleisdami jį visiems. Tai išgelbsti nuo daugelio klaidų ir netikėtumų. Taip pat yra detalūs logai, kur matote, kas tiksliai įvyko su kiekvienu kontaktu – kuris blokas suveikė, kada, kodėl.

CRM funkcionalumas ir kontaktų valdymas

Brevo CRM nėra tokia išplėsta kaip specializuotose sistemose tipo „Salesforce” ar „Pipedrive”, bet daugeliui įmonių jos tikrai pakanka. Galite sekti sandorius (deals), kurti pipeline’us, priskirti užduotis komandos nariams, matyti visą komunikacijos istoriją su klientu.

Kontaktų duomenų bazė leidžia saugoti beveik neribotą kiekį custom laukų. Galite turėti tekstinius, skaitinius, datos, boolean laukus – ką tik norite. Šie duomenys paskui naudojami segmentavimui ir personalizavimui. Importavimas veikia per CSV failus arba per API – abu būdai paprasti ir gerai dokumentuoti.

Segmentavimas paremtas šiais duomenimis. Galite kurti statinius sąrašus (manually pridedant kontaktus) arba dinaminius, kurie automatiškai atsinaujina pagal nustatytas taisykles. Pavyzdžiui, visi kontaktai iš Vilniaus, kurie paskutinius 30 dienų atidarė bent vieną el. laišką ir turi „premium” statusą. Tokios grupės atsinaujina realiu laiku.

Transactional el. laiškų siuntimas taip pat integruotas į platformą. Tai tie el. laiškai, kuriuos siunčia jūsų aplikacija – užsakymo patvirtinimai, slaptažodžio atkūrimas, pranešimai apie paskyros pakeitimus. Brevo SMTP serveriai yra patikimi, deliverability rodikliai geri, o API paprasta naudoti. Yra oficialūs SDK Python, PHP, Node.js, Ruby ir kitoms kalboms.

Landing page’ai ir formos

Brevo turi integruotą landing page kūrimo įrankį. Jis nėra toks galingas kaip specializuoti sprendimai tipo „Unbounce” ar „Leadpages”, bet paprastoms užduotims tikrai tinka. Galite sukurti prenumeratos puslapį, produkto pristatymo landing’ą, registracijos formą webinarui.

Redaktorius vėlgi „drag-and-drop”, su paruoštais blokais – antraštės, tekstai, paveikslėliai, formos, mygtukai. Responsive dizainas veikia automatiškai, nors kartais reikia rankiniu būdu pakoreguoti mobilią versiją, kad viskas atrodytų idealiai.

Kas patogiausia – landing page’ai hostinami Brevo serveriuose, tad nereikia jokio papildomo hosting’o. Galite naudoti savo domeną (per CNAME įrašą) arba Brevo subdomeną. SSL sertifikatai suteikiami automatiškai, tad viskas veikia per HTTPS.

Formos gali būti įterpiamos į jūsų svetainę arba naudojamos standalone landing page’uose. Yra keli tipai:

  • Inline formos (įterptos į puslapio turinį)
  • Pop-up formos (iššokantys langai)
  • Slide-in formos (išslystančios iš šono)

Galite nustatyti, kada forma turi pasirodyti – iš karto, po tam tikro laiko, kai vartotojas pradeda išeiti iš puslapio (exit intent), po nuscroolinto tam tikro kiekio turinio. Double opt-in funkcionalumas integruotas, kas svarbu GDPR atžvilgiu.

Analitika ir reportai

Duomenų vizualizacija Brevo nėra pati gražiausia, bet visa reikalinga informacija yra. Dashboard’e matote pagrindinius metrikus – siųstų el. laiškų skaičių, atidarymo rodiklius, paspaudimus, atsisakymus nuo prenumeratos, bounce rate.

Galite gilintis į kiekvienos kampanijos rezultatus atskirai. Matote ne tik bendrus skaičius, bet ir individualių kontaktų elgesį – kas atidarė, kas paspaudė, ant kokių nuorodų. Yra heat map funkcionalumas, rodantis, kurios nuorodos jūsų el. laiške sulaukia daugiausiai dėmesio.

A/B testavimas palaikomas, bet galėtų būti išplėstesnis. Galite testuoti siuntėjo vardą, tema, turinį. Platforma automatiškai paskirsto auditoriją į grupes ir po nustatyto laiko išrenka laimėtoją pagal jūsų pasirinktą metriką (atidarymai ar paspaudimai). Bet galite testuoti tik du variantus vienu metu, kai kai kurie konkurentai leidžia daugiau.

Reportai gali būti eksportuojami į CSV ar PDF. Taip pat galite nustatyti automatinius reportus, kurie bus siunčiami jums el. paštu kas savaitę ar mėnesį. Jei reikia gilesnės analitikos, galite naudoti API ir traukti duomenis į savo BI sistemas – „Google Data Studio”, „Tableau” ar ką nors panašaus.

Vienas iš naudingesnių dalykų – galite matyti, kuriuo paros metu jūsų auditorija aktyviausia. Brevo netgi gali automatiškai optimizuoti siuntimo laiką kiekvienam kontaktui atskirai, siųsdama tada, kai tas žmogus dažniausiai atidaro el. laiškus. Tai „Send Time Optimization” funkcija, kuri veikia tikrai neblogai.

API ir integracijos su kitomis sistemomis

Jei dirbate su Brevo kaip developeris, jų API tikrai neapvils. REST API yra gerai dokumentuota, su aiškiais pavyzdžiais įvairiomis programavimo kalbomis. Yra oficialūs SDK, kurie dar labiau supaprastina integraciją.

Per API galite daryti praktiškai viską, ką galite daryti per web interfeisą:

  • Valdyti kontaktus (kurti, atnaujinti, trinti)
  • Siųsti transactional el. laiškus ir SMS
  • Kurti ir valdyti kampanijas
  • Gauti statistiką ir reportus
  • Valdyti sąrašus ir segmentus
  • Kurti ir modifikuoti šablonus

Rate limits yra gana dosnūs – 300 užklausų per minutę free plane, o mokamose versijose dar daugiau. Tai turėtų pakakti net gana intensyviam naudojimui.

Webhook’ai leidžia gauti real-time pranešimus apie įvykius – el. laiško atidarymas, paspaudimas, bounce, spam skundas ir t.t. Tai labai patogu, jei norite sinchronizuoti duomenis su savo sistema arba trigger’inti kokius nors veiksmus savo aplikacijoje.

Kalbant apie native integracijas, Brevo palaiko daugybę populiarių platformų:

  • E-komercija: Shopify, WooCommerce, PrestaShop, Magento
  • CMS: WordPress, Drupal, Joomla
  • CRM: Salesforce, HubSpot, Pipedrive
  • Kitos: Zapier, Make (buvęs Integromat), Google Analytics, Facebook Ads

Zapier integracija ypač naudinga, nes ji atidaro duris į tūkstančius kitų aplikacijų. Galite kurti automatizacijas tipo „kai ateina naujas užsakymas Stripe, pridėti kontaktą į Brevo ir įtraukti į welcome seriją”.

Kainos ir tai, ką tikrai gaunate už savo pinigus

Brevo kainodara paremta kontaktų skaičiumi ir el. laiškų kiekiu. Yra nemokamas planas, kuris leidžia turėti neribotą kontaktų skaičių, bet siųsti tik 300 el. laiškų per dieną. Tai gali tikti mažoms įmonėms ar tiems, kas tik pradeda.

Mokamų planų kainos prasideda nuo apie 25 EUR per mėnesį už 20,000 el. laiškų per mėnesį. Tai gerokai pigiau nei „Mailchimp” ar „ActiveCampaign” už panašų funkcionalumą. Kas įdomu – Brevo neriboja kontaktų skaičiaus daugelyje planų, o tai didelis privalumas, jei turite didelę duomenų bazę, bet nesiunčiate labai dažnai.

SMS ir WhatsApp apmokestinami atskirai, pagal faktinį naudojimą. Tai sąžininga sistema – mokate tik už tai, ką naudojate. Kainos skiriasi priklausomai nuo šalies, bet paprastai jos rinkos vidurkio lygyje arba šiek tiek žemiau.

Enterprise planai siūlo papildomas funkcijas – dedikuotą IP adresą (svarbu deliverability), prioritetinį palaikymą, papildomus vartotojus, sub-accounts valdymą. Jei siunčiate daugiau nei milijoną el. laiškų per mėnesį, verta susisiekti dėl individualios kainos.

Vienas dalykas, kurį pastebėjau – Brevo neturi tokių agresyvių upsell taktikų kaip kai kurie konkurentai. Jie neužrakina esminių funkcijų už premium planus. Net nemokamame plane turite prieigą prie automatizavimo, landing page’ų, CRM. Tai tikrai vertiname.

Kas veikia gerai ir kur dar yra ką tobulinti

Padirbėjus su Brevo keletą mėnesių, susidaro gana aiškus vaizdas apie platformos stipriąsias ir silpnąsias puses. Deliverability rodikliai tikrai geri – el. laiškai pasiekia inbox’us, o ne spam aplankus. Tai vienas iš svarbiausių dalykų, ir Brevo čia tikrai stengiasi. Jie turi gerus santykius su pagrindiniais el. pašto provideriais, valdo savo IP reputaciją, teikia DKIM ir SPF konfigūracijos pagalbą.

Klientų palaikymas veikia neblogai, nors ne idealiai. Atsakymo laikas paprastai 24 valandos ar greičiau, bet kartais jaučiasi, kad support komanda dirba pagal scriptus ir ne visada gali padėti su sudėtingesnėmis techninėmis problemomis. Dokumentacija išsami, bet kartais pasitaiko застаревшios informacijos – funkcionalumas atsinaujina greičiau nei docs.

Interfeisas intuityvus, bet dizainas galėtų būti šiuolaikiškesnis. Kai kurie meniu ir nustatymai paslėpti ne pačiose logiškiausiose vietose. Pavyzdžiui, transactional el. laiškų nustatymai yra atskirame skyriuje nuo marketing kampanijų, kas iš pradžių gali suklaidinti.

Automatizavimo įrankis galingas, bet vizualinis workflow redaktorius kartais lėtokas, kai turite labai sudėtingą schemą su daugybe šakojimų. Taip pat trūksta versioning funkcionalumo – jei kažką sugadinote workflow, negalite grįžti į ankstesnę versiją, nebent darėte backup’ą rankiniu būdu.

A/B testavimo galimybės, kaip minėjau, galėtų būti išplėstesnės. Konkurentai leidžia testuoti daugiau nei du variantus vienu metu, testuoti skirtingus siuntimo laikus, automatiškai optimizuoti rezultatus. Brevo čia šiek tiek atsilieka.

Bet bendrai – už savo kainą Brevo siūlo tikrai solidų funkcionalumą. Tai ne pats pigiausias sprendimas rinkoje, bet tikrai vienas iš geriausių value for money atžvilgiu. Jei ieškote all-in-one platformos, kuri apimtų el. paštą, SMS, WhatsApp, CRM, automatizavimą ir landing page’us – Brevo tikrai verta rimto dėmesio. Ypač jei nesate pasiruošę mokėti „HubSpot” ar „Salesforce Marketing Cloud” kainų, bet norite daugiau nei siūlo „Mailchimp” ar „Constant Contact”.

HTML kodo kokybė, kurią generuoja el. laiškų redaktorius, yra gera. Laiškai atrodo gerai visose pagrindinėse el. pašto klientų programose, įskaitant problematiškus „Outlook” variantus. Tai svarbu, nes niekas nenori, kad jų kruopščiai sukurtas dizainas subyrėtų į gabalus Gmail ar Apple Mail aplikacijose.

Migracija iš kitų platformų paprastai sklanduška. Brevo turi importavimo įrankius, kurie palaiko daugumą populiarių formatų. Tačiau verta skirti laiko duomenų valymui prieš migravimą – importuokite tik aktyvius, engaged kontaktus, nes tai pagerins jūsų sender reputaciją naujoje platformoje.

Taigi, jei planuojate išbandyti Brevo, pradėkite nuo nemokamo plano, sukurkite keletą test kampanijų, pažaiskite su automatizavimo įrankiais. Platforma tikrai verta laiko, o jei ji atitiks jūsų poreikius – investicija į mokamą planą greitai atsipirks geresniu engagement’u ir efektyvesniu marketingu.

„Kartra” all-in-one marketingo platforma

by adminin E-komercijaLeave a Comment on „Kartra” all-in-one marketingo platforma

Kas ta Kartra ir kodėl apie ją visi kalba

Jei dirbi su internetiniu verslu ar skaitmenine rinkodara, tikriausiai jau girdėjai apie „all-in-one” platformas. Rinka jų pilna – nuo ClickFunnels iki Kajabi, visi žada būti tuo vieninteliu įrankiu, kurio tau reikia. Kartra čia nėra išimtis, bet ji tikrai turi savo charakterį.

Pirmą kartą susidūrus su Kartra, iškart pastebėsi, kad tai nėra dar vienas paprastas landing page kūrimo įrankis. Tai tikrai išsiplėtusi ekosistema, kuri bando apjungti email marketingą, pardavimo piltuves, narystės svetaines, mokėjimų apdorojimą ir dar daugybę kitų funkcijų po vienu stogu. Skamba kaip svajonė? Na, priklauso.

Platforma atsirado maždaug 2018 metais ir nuo to laiko sugebėjo susikurti gana lojalią bendruomenę. Ypač populiari tarp online kursų kūrėjų, coachų ir info produktų pardavėjų. Kodėl? Nes ji iš tiesų leidžia atsisakyti kelių skirtingų prenumeratų ir viską valdyti vienoje vietoje.

Funkcionalumas, kuris tikrai veikia

Pradėkime nuo to, kas Kartroje veikia gerai. Pirmiausia – email marketing sistema. Ji nėra tokia galingai analitinė kaip ActiveCampaign, bet daugumui vartotojų jos pakanka su kaupu. Gali kurti automatizacijas, segmentuoti auditorijas, siųsti broadcast kampanijas. Sąsaja intuityvesnė nei daugelio konkurentų, o tai reiškia, kad nesugaiši pusės dienos bandydamas suprasti, kaip nustatyti paprastą autoresponder seką.

Pardavimo piltuvo kūrimas – čia Kartra tikrai žiba. Drag-and-drop redaktorius leidžia greitai sukurti visą pardavimo procesą nuo landing page iki thank you puslapio. Šablonų biblioteka nėra milžiniška, bet kokybė gera. Svarbiausia – viską gali pritaikyti be jokio kodavimo. Ir taip, puslapiai responsive, nors kartais tenka pakoreguoti mobilią versiją rankiniu būdu.

Mokėjimų integracija su Stripe ir PayPal veikia sklandžiai. Galima nustatyti įvairius mokėjimo planus – vienkartiniai, prenumeratos, išsimokėtinai. Bump offers, upsells, downsells – visa klasika čia yra. Vienintelis minusas – kai kuriose šalyse Stripe palaikymas ribotas, tai gali būti problema.

Narystės svetainės ir kursų hostingas

Jei planuoji kurti online kursus ar membership site, Kartra turi visus reikalingus įrankius. Galima įkelti video turinį, PDF failus, audio įrašus. Yra drip content funkcionalumas – t.y. galima nustatyti, kad turinys būtų prieinamas palaipsniui pagal tvarkaraštį.

Kas man asmeniškai patinka – video hostingas įtrauktas į kainą. Nereikia mokėti papildomai už Vimeo ar Wistia. Kartra video grotuvas gana pagrindinis, bet turi esminius dalykus: galima kontroliuoti atsisiuntimą, peržiūros greitį, pridėti CTA mygtukus.

Narystės lygių valdymas paprastas. Gali sukurti skirtingus prieigos lygius, riboti turinį pagal prenumeratos tipą. Integracija su email sistema reiškia, kad gali automatiškai siųsti priminimus, kai baigiasi prenumerata ar kai narys neaktyvus tam tikrą laiką.

Tačiau būkime sąžiningi – jei kuri labai sudėtingą edukacinę platformą su gamifikacija, pažangiu testavimu ir sudėtinga hierarchija, Kartra gali pasirodyti per paprasta. Tokiais atvejais Teachable ar Thinkific būtų geresni pasirinkimai.

Kalendoriaus ir susitikimų sistema

Viena iš funkcijų, kuri išskiria Kartrą nuo daugelio konkurentų – integruotas kalendoriaus įrankis. Panašus į Calendly, bet jau įtrauktas į platformą. Gali nustatyti savo darbo valandas, leisti klientams užsiregistruoti konsultacijoms, automatiškai siųsti priminimus.

Integracija su Zoom ir Google Calendar veikia be problemų. Kai kas užsiregistruoja susitikimui, automatiškai sukuriamas įvykis tavo kalendoriuje ir išsiunčiamas patvirtinimas klientui. Gali nustatyti buffer laiką tarp susitikimų, maksimalų susitikimų skaičių per dieną ir kitus parametrus.

Ar tai pakeičia specializuotus įrankius kaip Calendly ar Acuity? Ne visai. Funkcionalumas bazinis, bet daugumai smulkių verslų jo pakanka. Didžiausias privalumas – viena prenumerata mažiau.

Helpdesk ir klientų aptarnavimas

Kartra turi ir helpdesk sistemą, kuri leidžia valdyti klientų užklausas. Gali sukurti ticket sistemą, priskirti užklausas skirtingiems komandos nariams, sekti atsakymo laiką.

Atvirai kalbant, ši funkcija yra viena silpniausių platformoje. Jei turi rimtą verslą su dideliu klientų srautu, greičiausiai vis tiek naudosi Zendesk ar Intercom. Bet jei tavo palaikymo apimtys nedidelės, Kartra helpdesk gali būti pakankamas.

Yra ir live chat funkcionalumas, kurį gali įdiegti į savo svetainę. Vėlgi – bazinis, bet veikiantis. Galima nustatyti automatines žinutes, integruoti su email sistema, matyti lankytojo istoriją.

Analitika ir ataskaitų sistema

Kiekviena marketingo platforma giriasi savo analitika, bet realybė dažnai nuvilia. Kartra šioje srityje yra kažkur viduryje. Dashboard’as rodo pagrindinius metrikus – pardavimus, konversijas, email open rates, click rates. Galima matyti, kurie piltuvo etapai veikia gerai, o kur žmonės išbyra.

Kas trūksta – gilesnės analitikos. Jei nori tikrai suprasti vartotojo kelionę, A/B testų rezultatus ar sudėtingesnius conversion path’us, Kartra duomenų gali nepakakti. Daugelis vartotojų papildomai naudoja Google Analytics ar kitus specializuotus įrankius.

Pozityvu tai, kad visos ataskaitos realaus laiko. Nereikia laukti, kol duomenys atsinaujins. Tai ypač patogu, kai leidžiama nauja kampanija ir nori matyti rezultatus iškart.

Kainodara ir kas už ją gauni

Gerai, dabar apie skaudžią temą – kainą. Kartra nėra pigi. Starter planas prasideda nuo $99 per mėnesį (jei moki metams iš anksto, išeina apie $79/mėn). Tai jau rimta investicija, ypač jei tik pradedi.

Už tuos pinigus gauni:

  • Iki 2,500 email kontaktų
  • Iki 15,000 email siuntimų per mėnesį
  • 100 puslapių
  • 2 narystės produktus
  • 20GB bandwidth video

Silver planas ($199/mėn arba $149 metinei prenumeratai) jau duoda daugiau erdvės – 12,500 kontaktų, 125,000 email’ų, neribotus puslapius ir produktus.

Gold ($299/mėn) ir Platinum ($499/mėn) planai skirti didesniems verslams su atitinkamai didesnėmis limitais.

Ar verta? Priklauso nuo to, kiek įrankių pakeičia. Jei dabar moki už email platformą ($50), landing page kūrėją ($50), narystės svetainės hostingą ($50), kalendoriaus įrankį ($15) ir dar porą dalykų – Kartra gali būti ekonomiškesnis variantas. Bet jei tik pradedi ir dar neturi klientų bazės, kaina gali atrodyti įbauginanti.

Realūs iššūkiai ir ką reikia žinoti prieš pradedant

Dabar apie tai, ko pardavimo puslapyje neskaitysi. Pirma – mokymosi kreivė. Nors Kartra skelbiasi esanti user-friendly, realybė tokia, kad pirmą savaitę jausiesi truputį pasimetęs. Platforma turi tiek daug funkcijų, kad net sunku suprasti, nuo ko pradėti.

Mano patarimas – neskubėk. Pradėk nuo vieno dalyko. Pavyzdžiui, sukurk paprastą landing page su email forma. Paskui pridėk automatizaciją. Po to – mokėjimo procesą. Bandymas viską sukonfigūruoti iš karto baigiasi frustracija.

Antra problema – techninė pagalba. Nors Kartra turi support komandą, atsakymo laikas kartais būna ilgas. Yra knowledge base ir video tutorialai, bet kai susiduri su specifine problema, gali prireikti kantrybės. Facebook bendruomenė dažnai būna greitesnė pagalbos šaltinis nei oficialus support.

Trečia – integracijos. Nors Kartra turi Zapier integraciją, kuri teoriškai leidžia jungtis su tūkstančiais kitų įrankių, praktikoje ne viskas veikia sklandžiai. Jei tavo verslas labai priklauso nuo specifinių integracijų su nišiniais įrankiais, patikrink suderinamumą prieš įsipareigodamas.

Dar vienas dalykas – puslapių greitis. Kartroje sukurti puslapiai kartais kraunasi lėčiau nei norėtųsi. Tai gali turėti įtakos SEO ir conversion rates. Optimizuok paveikslėlius, naudok minimalų dizainą, vengk per daug skriptų.

Kam Kartra tikrai tinka ir kam geriau ieškoti alternatyvų

Po kelių mėnesių darbo su Kartra, galiu pasakyti, kad ji puikiai tinka vidutinio dydžio info produktų verslams. Jei parduodi online kursus, coaching programas, membership’us ar skaitmeninius produktus – Kartra bus geras pasirinkimas.

Taip pat tinka, jei:

  • Nori sumažinti įrankių skaičių ir viską valdyti vienoje vietoje
  • Neturi programavimo įgūdžių, bet nori profesionaliai atrodančią svetainę
  • Tau svarbu email marketingas ir pardavimo automatizacija
  • Planuoji augti ir reikia platformos, kuri skaluojasi

Bet Kartra netinka, jei:

  • Tik pradedi ir dar neturi validuoto verslo modelio (per brangu eksperimentuoti)
  • Tau reikia labai specifinių funkcijų, kurias teikia specializuoti įrankiai
  • Tavo verslas labai priklauso nuo sudėtingų integracijų
  • Nori maksimalios SEO kontrolės ir greitų, custom coded puslapių

Alternatyvos? ClickFunnels 2.0 yra panašus, bet brangesnis ir labiau orientuotas į piltuvo kūrimą. Kajabi geresnis kursų kūrimui, bet silpnesnis email marketinge. Systeme.io pigesnė, bet turi mažiau funkcijų. GetResponse turi panašų all-in-one požiūrį ir gali būti geresnė alternatyva, jei email marketingas tau svarbiausias.

Galiausiai, ar Kartra yra tobula platforma? Tikrai ne. Ar ji gali pakeisti daugybę įrankių ir supaprastinti tavo tech stack’ą? Absoliučiai taip. Viskas priklauso nuo tavo verslo poreikių, biudžeto ir noro išmokti naują sistemą. Jei turi resursų investuoti laiką į mokymąsi ir biudžetą prenumeratai, Kartra gali tapti tavo verslo stuburu. Jei ne – galbūt geriau pradėti nuo paprastesnių ir pigesnių sprendimų, kol verslas išaugs. Svarbu ne įrankis, o kaip jį naudoji. Geriau puikiai išmanyti vieną platformą nei vidutiniškai naudoti penkias.

Butter CMS API-first content platforma

by adminin E-komercijaLeave a Comment on Butter CMS API-first content platforma

Kas ta Butter CMS ir kodėl ji išsiskiria iš minios

Jei esi bent kiek susipažinęs su šiuolaikinėmis content management sistemomis, turbūt žinai, kad tradiciniai CMS sprendimai kaip WordPress ar Drupal pradeda gerokai atsilikti nuo to, ko reikia moderniems projektams. Čia ir ateina į žaidimą Butter CMS – API-first platforma, kuri žada išspręsti daugelį headless CMS pasaulio problemų.

Butter CMS pozicionuoja save kaip „drop-in” sprendimą, kuris leidžia greitai integruoti content management funkcionalumą į bet kokią aplikaciją. Skirtingai nuo tradicinių CMS, kur frontend ir backend yra susieti kartu, Butter veikia kaip grynai backend servisas, teikiantis turinį per RESTful API arba webhooks. Tai reiškia, kad tavo frontend gali būti parašytas React, Vue, Angular, ar net vanilla JavaScript – Butter CMS tiesiog nekreipia dėmesio.

Kas įdomu, Butter nėra tik dar vienas „headless WordPress” klonas. Jie nuo pat pradžių projektavo sistemą būtent kaip API-first sprendimą, o ne bandė priklijuoti API prie egzistuojančios monolitinės architektūros. Tai jaučiasi naudojant produktą – viskas tiesiog veikia sklandžiau nei tikėtumeis.

Architektūra ir techninis įgyvendinimas

Butter CMS architektūra paremta keliais pagrindiniais principais, kurie daro ją patrauklią developeriams. Pirma, tai pilnai valdomas (fully managed) SaaS sprendimas. Nereikia rūpintis serveriais, skaliavimu, backup’ais ar saugumo atnaujinimais. Antra, jie naudoja CDN infrastruktūrą content delivery’ui, kas reiškia greitą turinio pristatymą nepriklausomai nuo geografinės lokacijos.

API dizainas yra intuityvus ir gerai dokumentuotas. Visi endpoint’ai grąžina JSON formatą, o autentifikacija vyksta per API token’us. Nėra jokių sudėtingų OAuth flow’ų, jei tau jų nereikia – tiesiog įmeti token’ą į request header’į ir viskas veikia. Tai gali skambėti paprastai, bet tikėk manimi, kai dirbi su deadline’ais, tokia paprastumas yra palaiminimas.

Vienas iš stipriausių Butter pusių yra jų SDK bibliotekos. Jie palaiko praktiškai visas populiarias programavimo kalbas ir framework’us: JavaScript/Node.js, Python, Ruby, PHP, .NET, Java, Go. Kiekviena biblioteka yra gerai palaikoma ir reguliariai atnaujinama. Pavyzdžiui, jų JavaScript SDK leidžia fetch’inti content’ą vos keliais kodo eilutėmis:

„`javascript
butter.page.retrieve(‘*’, ‘landing-page’)
.then(function(resp) {
console.log(resp.data.data);
});
„`

Content modeliavimas ir struktūrizavimas

Butter CMS siūlo du pagrindinius content organizavimo būdus: Pages ir Collections. Pages yra skirtos unikaliam turiniui – landing page’ams, about puslapiams, case studies ir panašiai. Collections, kita vertus, tinka pasikartojančiam turiniui kaip blog post’ai, produktų katalogai, team member’ių profiliai.

Kas man asmeniškai patinka – tai jų komponentų sistema. Galima sukurti reusable content komponentus (jie vadina juos „components” arba „modules”), kuriuos paskui galima drag-and-drop būdu dėlioti į puslapius. Pavyzdžiui, gali turėti „Hero Section” komponentą su nuotrauka, antrašte ir CTA mygtuku, „Testimonials Grid” komponentą su klientų atsiliepimais, ir taip toliau.

Šie komponentai nėra tik content laukeliai – jie turi savo schema, validation rules, ir gali būti nested. Tai leidžia sukurti tikrai sudėtingas content struktūras, bet išlaikyti juos lengvai valdomas content editor’iams. Techinis žmogus gali sukurti schema, o marketingo komanda gali laisvai kurti ir redaguoti turinį be developer’io pagalbos.

Field tipai yra standartiniai bet pakankami: text, textarea, WYSIWYG, number, date, media (images/files), reference (ryšiai tarp content tipų). Nieko revoliucingo, bet viskas ko reikia praktikoje. Vienas trūkumas – nėra built-in lokalizacijos mechanizmo field lygyje, nors galima implementuoti per custom sprendimus.

Developer experience ir integracija

Jei tave domina, kaip greitai galima pradėti dirbti su Butter CMS, atsakymas – labai greitai. Jų onboarding procesas yra vienas geriausių, kuriuos esu matęs. Registruojiesi, gauni API token’ą, ir per 10 minučių jau gali fetch’inti content’ą į savo aplikaciją.

Dokumentacija yra išties gera. Ne tik API reference su visais endpoint’ais, bet ir praktiniai tutorial’ai konkretiems use case’ams. Nori integruoti su Next.js? Yra step-by-step guide’as. Nori naudoti su Gatsby? Yra oficialus plugin’as ir dokumentacija. React, Vue, Angular – viskas aprašyta su code example’ais.

Webhook’ai veikia patikimai, kas svarbu, jei nori implementuoti automatic rebuild’us static site generator’iams. Kai content editor’ius publikuoja ar atnaujina turinį, Butter gali trigger’inti webhook’ą į tavo CI/CD pipeline’ą. Mes naudojame tai su Netlify ir Vercel – veikia kaip laikrodis.

Preview funkcionalumas irgi gerai pagalvotas. Galima sukurti preview URL’us, kurie rodo unpublished content’ą, kas leidžia content kūrėjams matyti, kaip atrodys jų pakeitimai prieš publikuojant. Tai gali skambėti kaip basic feature’as, bet daugelis headless CMS sprendimų tai implementuoja labai nepatogiai.

Content management sąsaja ir editor’iaus patirtis

Vienas dalykas, kurį Butter CMS daro geriau už daugelį konkurentų – tai jų dashboard’o UI. Jis nėra perkrautas funkcijomis, bet kartu nėra ir per supaprastintas. Content editor’iai, kurie nėra techniniai, gali lengvai suprasti, kaip viskas veikia, be ilgų mokymų.

WYSIWYG editor’ius yra paremtas Quill biblioteka ir veikia stabiliai. Palaiko visus standartinius formatavimo veiksmus, media įterpimą, linkus. Nėra jokių keistų bug’ų ar netikėto elgesio, kaip kartais būna su WordPress Gutenberg ar kitais „moderniais” editor’iais.

Media biblioteka yra paprasta bet funkcionali. Galima upload’inti nuotraukas ir failus, organizuoti juos į folder’ius, pridėti alt text’us ir kitus metadata. Automatinis image resizing ir optimization’as veikia out of the box. Vienintelis trūkumas – nėra advanced image editing funkcijų, bet tam ir yra kiti įrankiai.

Roles ir permissions sistema yra pakankamai detaliai. Galima sukurti skirtingus user role’us su specifiniais leidimais – kas gali kurti content’ą, kas gali publikuoti, kas gali tvarkyti settings. Tai svarbu didesniems team’ams, kur ne visi turėtų turėti full access.

Performance ir skaliavilumas

Vienas svarbiausių klausimų bet kuriam CMS – kaip jis elgiasi su apkrova? Butter CMS šioje srityje tikrai nepasimeta. Kadangi jie naudoja CDN infrastruktūrą, API response laikai yra labai geri – paprastai 50-150ms, priklausomai nuo geografinės lokacijos ir request sudėtingumo.

Jie garantuoja 99.9% uptime SLA, ir pagal mano patirtį, jie šį pažadą laiko. Per pastaruosius metus, kai naudojame Butter production’e, turėjome tik vieną trumpą outage’ą, kuris truko apie 15 minučių. Jų status page yra skaidrus ir rodo real-time metrikas.

Rate limiting yra įgyvendintas protingai. Priklausomai nuo plan’o, gauni tam tikrą skaičių API request’ų per mėnesį. Bet jie neskaičiuoja CDN cached request’ų, kas reiškia, kad jei tavo content’as yra cache’inamas, gali turėti praktiškai unlimited traffic’ą be papildomų mokesčių. Tai didelis skirtumas nuo kai kurių konkurentų, kurie skaičiuoja kiekvieną request’ą.

Caching strategija yra flexible. Galima kontroliuoti cache headers, invalidate cache programmatically per API, arba naudoti jų automatic cache invalidation, kai content’as atnaujinamas. Tai leidžia rasti balansą tarp performance ir content freshness.

Pricing ir verslo aspektai

Kalbant apie pinigus – Butter CMS nėra pigiausias sprendimas rinkoje, bet ir ne brangiausias. Jų pricing modelis yra paremtas API request’ų skaičiumi ir funkcionalumo lygiu. Starter plan’as prasideda nuo apie $83/mėn (kainos keičiasi, tai check’ink official website), kas gali atrodyti daug, palyginus su self-hosted WordPress, bet reikia įvertinti, ką gauni už tuos pinigus.

Pirma, nereikia mokėti už hosting’ą, serverio administravimą, backup’us, security monitoring’ą. Antra, developer’io laikas, kurį sutaupai naudodamas ready-made sprendimą vietoj custom CMS kūrimo, yra žymiai brangesnis. Trečia, jų support yra tikrai geras – atsako greitai ir su konkrečiais sprendimais, ne generic copy-paste atsakymais.

Vienas dalykas, kurį reikia turėti omenyje – jei tavo projektas auga ir API request’ų skaičius viršija plan’o limitą, kaina gali greitai kilti. Bet čia ir vėl – jei tinkamai naudoji caching’ą (o turėtum), šis limitas turėtų būti daugiau nei pakankamas daugumai projektų.

Jie siūlo ir enterprise plan’us su custom pricing, SLA garantijomis, dedicated support, ir kitomis enterprise features. Jei dirbi su dideliu klientu, kuris reikalauja tokių dalykų, Butter gali tai suteikti.

Realūs use case’ai ir kada Butter CMS yra tinkamas pasirinkimas

Per pastaruosius kelerius metus esu naudojęs Butter CMS keliuose projektuose, ir galiu pasakyti, kur jis tikrai šviečia, o kur galbūt ne geriausias pasirinkimas.

Idealus scenario – tai marketing website’ai ir landing page’ai, kurie reikalauja dažnų content atnaujinimų be developer’io įsikišimo. Pavyzdžiui, SaaS kompanijos website’as su blog’u, case studies, product pages. Butter leidžia marketing team’ui valdyti visą content’ą savarankiškai, o developer’iai gali fokusinti į funkcionalumą ir integraciją su kitomis sistemomis.

Kitas geras use case’as – multi-platform content delivery. Jei tavo content’as turi būti prieinamas web aplikacijoje, mobile app’e, ir galbūt dar kažkur kitur, Butter API-first approach’as leidžia lengvai fetch’inti tą patį content’ą į visas platformas. Vienas content source, daug consumption point’ų.

E-commerce projektams, kur reikia valdyti product content’ą atskirai nuo inventory ir checkout logikos, Butter irgi gali būti geras fit’as. Galima integruoti su Shopify, WooCommerce ar custom e-commerce backend’u, naudojant Butter tik content management’ui.

Tačiau yra scenarijai, kur Butter gali nebūti geriausias pasirinkimas. Jei reikia labai sudėtingų content relationships, advanced workflow’ų su multiple approval stages, ar highly custom admin UI – gali būti, kad Contentful ar Sanity bus geresni variantai. Jei biudžetas labai ribotas ir projektas mažas – galbūt Strapi (open-source) ar net tradicinis WordPress su REST API bus praktišesnis.

Taip pat reikia įvertinti vendor lock-in riziką. Nors Butter turi export funkcionalumą, migracija nuo jų į kitą sistemą nėra triviali. Bet tai problema su bet kuriuo SaaS sprendimu – reikia svarstyti trade-off’us tarp convenience ir kontrolės.

Ką reikia žinoti prieš pradedant projektą su Butter

Jei nusprendei, kad Butter CMS tinka tavo projektui, štai keletas praktinių patarimų, kurie padės išvengti įprastų klaidų ir maksimizuoti efektyvumą.

Pirma, praleisk laiko content modeling’ui prieš pradedant development’ą. Butter leidžia keisti content struktūras vėliau, bet jei turi daug content’o, migracijos gali būti skausmingos. Pagalvok apie tai, kokie content tipai tau reikės, kaip jie bus susiję tarpusavyje, kokius laukus kiekvienas tipas turės. Geriau praleisti extra valandą planning’ui nei tris dienas refactoring’ui vėliau.

Antra, setup’ink proper caching strategy nuo pat pradžių. Butter API yra greitas, bet nėra priežasties daryti API call’ą kiekvienam page view’ui, jei content’as nesikeičia kas minutę. Next.js ISR (Incremental Static Regeneration), Gatsby build cache, ar tiesiog Redis cache layer – pasirink tai, kas tinka tavo stack’ui, bet būtinai implementuok caching’ą.

Trečia, naudok jų webhook’us automation’ui. Automatic rebuild’ai, cache invalidation, Slack notifications apie content publikacijas – visa tai galima lengvai setup’inti per webhook’us. Tai sutaupo daug manual work’o ir sumažina klaidų riziką.

Ketvirta, sukurk development ir staging environment’us. Butter leidžia turėti multiple spaces (environments), nors tai gali reikalauti aukštesnio plan’o. Jei negali sau leisti multiple paid spaces, bent jau naudok preview funkcionalumą testavimui prieš publikuojant į production’ą.

Penkta, dokumentuok savo content struktūras ir komponentus. Kai projektas auga, lengva pamiršti, kodėl tam tikri laukai egzistuoja ar kaip tiksliai veikia tam tikri komponentai. Paprastas README failas su content type aprašymais gali sutaupyti daug laiko naujiems team member’iams ar tau pačiam po kelių mėnesių.

Ir galiausiai – nepamirški, kad Butter yra tik content layer. Jis nesukurs tavo frontend’o, netvarkys authentication, nedarys payment processing. Tai yra jo stiprybė (focus on one thing and do it well), bet reiškia, kad tau reikės integruoti jį su kitais tools ir services. Planuok savo architektūrą atitinkamai.

Butter CMS tikrai nėra tobulas sprendimas, bet jis yra solid, patikimas, ir developer-friendly įrankis, kuris gali žymiai paspartinti tavo projektų delivery’į. Jei ieškote headless CMS, kuris veikia iš dėžės be daug konfigūracijos, bet vis tiek suteikia pakankamai flexibility advanced use case’ams – Butter tikrai vertas tavo dėmesio. Tik nepamirški įvertinti savo specifinių reikalavimų ir biudžeto prieš commit’indamas prie bet kurio vendor’io. Ir kaip visada – padaryk proof of concept su savo use case’u prieš naudodamas production’e. Free trial yra tam, kad juo pasinaudotum.

„Omnisend” SMS marketingo integracija

by adminin E-komercija, Internetinės parduotuvėsLeave a Comment on „Omnisend” SMS marketingo integracija

Kodėl SMS marketingas vis dar svarbus 2025-aisiais

Kalbant apie marketingo kanalus, daugelis iš mūsų pirmiausiai galvojame apie el. paštą, socialinę mediją ar galbūt push pranešimus. Tačiau SMS žinutės išlieka vienas efektyviausių būdų pasiekti klientus – jų atidarymo rodiklis siekia net 98%, o dauguma žmonių perskaitė žinutę per pirmas tris minutes po gavimo. Tai ypač aktualu e-commerce verslui, kur laiko veiksnys dažnai lemia, ar klientas užbaigs pirkimą, ar paliks pilną krepšelį.

„Omnisend” platformoje SMS integracija nėra tik papildoma funkcija – tai pilnavertis marketingo kanalas, kuris gali veikti kartu su el. paštu, sukuriant galingas automatizuotas kampanijas. Bet prieš įsigilinant į techninius dalykus, verta suprasti, kodėl apskritai turėtumėte apsvarstyti SMS kaip marketingo kanalą.

Pagrindinė SMS pranašumas – tiesioginis ir asmeniškas kontaktas. Kai klientas gauna žinutę telefone, jis beveik garantuotai ją pastebės. Tai nereiškia, kad reikia bombarduoti klientus kasdienėmis žinutėmis, bet strategiškai panaudojus šį kanalą kritiniais momentais (apleistas krepšelis, užsakymo atnaujinimai, specialūs pasiūlymai), rezultatai gali būti įspūdingi.

Kaip veikia SMS integracija „Omnisend” platformoje

Technine prasme, „Omnisend” SMS funkcionalumas yra integruotas tiesiai į platformą, todėl jums nereikia jokių papildomų įrankių ar sudėtingų API integracijų. Tai vienas iš didžiausių privalumų, ypač mažesnėms komandoms, kurios neturi atskirų programuotojų, skirtų marketingo sistemoms prižiūrėti.

Pradėti naudoti SMS galite tiesiog įjungę šią funkciją savo „Omnisend” paskyroje ir įkėlę kreditus. Taip, SMS žinutės yra mokamos papildomai – tai ne kaip el. pašto kampanijos, kur galite siųsti neribotai pagal savo planą. Kaina priklauso nuo šalies, į kurią siunčiate žinutes. Pavyzdžiui, žinutė į JAV kainuoja apie 0.015-0.02 USD, o į Europą gali būti šiek tiek brangiau.

Kas tikrai patogu – galite kurti kombinuotas kampanijas, kur el. paštas ir SMS veikia kartu. Pavyzdžiui, pirma siunčiate el. laišką apie išpardavimą, o po kelių valandų tiems, kurie jo neatidarė, siunčiate SMS priminimą. Arba atvirkščiai – SMS kaip pirminis pranešimas, o el. paštas su daugiau detalių.

Telefono numerių surinkimas ir GDPR

Prieš pradedant siųsti SMS, reikia turėti telefono numerių bazę. Čia svarbu laikytis taisyklių – ypač jei dirbate su Europos klientais. GDPR reikalauja aiškaus sutikimo, todėl negalite tiesiog paimti numerių iš užsakymų ir pradėti siųsti marketingo žinutes.

„Omnisend” leidžia kurti registracijos formas su atskiru sutikimo laukeliu SMS žinutėms. Galite įdėti tokią formą į savo svetainę, pasiūlyti nuolaidą už registraciją, ir taip organiškai auginti savo SMS prenumeratorių sąrašą. Svarbu aiškiai nurodyti, kokio tipo žinutes klientai gaus ir kaip dažnai.

Praktinis patarimas: nepamirškite įtraukti opt-out mechanizmo. Kiekviena SMS žinutė turėtų turėti galimybę atsisakyti prenumeratos (paprastai tai būna „Atsakyk STOP”). „Omnisend” tai tvarko automatiškai, bet vis tiek verta patikrinti, ar viskas veikia teisingai.

Automatizuotų SMS kampanijų kūrimas

Čia prasideda tikrasis malonumas. „Omnisend” leidžia kurti automatizuotus workflow, kur SMS gali būti integruotas į sudėtingesnius scenarijus. Štai keletas pavyzdžių, kurie realiai veikia:

Apleisto krepšelio serija: Kai klientas prideda produktų į krepšelį, bet neužbaigia pirkimo, po valandos siunčiate el. laišką. Jei po 3 valandų jis vis dar nesugrįžo, siunčiate SMS su tiesioginiu linku į krepšelį. Statistika rodo, kad SMS šiame etape gali padidinti konversijas net 20-30%.

Užsakymo patvirtinimas ir pristatymas: Nors tai labiau transakcinis turinys, klientai tikrai vertina SMS pranešimus apie užsakymo būseną. Galite nustatyti automatinius pranešimus, kai užsakymas patvirtinamas, išsiunčiamas ir pristatomas.

VIP klientų programos: Segmentuokite geriausius klientus ir siųskite jiems ekskluzyvius pasiūlymus per SMS prieš kitiems. Tai sukuria išskirtinumo jausmą ir stiprina lojalumą.

Gimtadienio kampanijos: Jei renkate gimimo datas, SMS su asmeniniu sveikinimų ir nuolaidos kodu gali būti labai efektyvus. Žmonės dažniau atidaro ir naudoja tokius pasiūlymus, kai jie ateina per SMS.

Workflow kūrimo praktika

Kurdami automatizuotus workflow su SMS, svarbu nepervertinti šio kanalo. SMS turėtų būti naudojamas strategiškai – kritiniuose taškuose, kur tikrai reikia klientų dėmesio. Jei siųsite per daug SMS, žmonės greitai atsisakys prenumeratos.

Gera praktika – naudoti laiko vėlavimus ir sąlygas. Pavyzdžiui, jei klientas jau atidarė el. laišką ir paspaudė ant nuorodos, nebereikia siųsti SMS. „Omnisend” leidžia nustatyti tokias sąlygas workflow viduje, todėl galite kurti protingas kampanijas, kurios neerzina klientų.

Dar vienas patarimas – testuokite siuntimo laiką. SMS žinutės yra labai intruzyvios, todėl siunčiant jas naktį ar labai anksti ryte galite sukelti neigiamą reakciją. Nustatykite „quiet hours” savo kampanijose – paprastai nuo 21:00 iki 9:00 geriau nesiunčiama.

Segmentacija ir personalizacija SMS kampanijose

Vienas didžiausių „Omnisend” privalumų – galinga segmentacijos sistema. Galite kurti segmentus pagal beveik bet kokius kriterijus: pirkimo istoriją, naršymo elgesį, geografinę vietą, įsitraukimo lygį ir t.t.

SMS kontekste segmentacija tampa dar svarbesnė, nes kiekviena žinutė kainuoja pinigų. Nėra prasmės siųsti tos pačios žinutės visiems – geriau identifikuoti tikslines grupes ir pritaikyti pranešimus konkrečiai jiems.

Pavyzdžiui, jei parduodate drabužius, galite segmentuoti pagal lytį, amžių ar ankstesnius pirkimus. Vyrams, kurie pirko sportbačius, galite siųsti SMS apie naujų sportinių prekių kolekciją. Moterims, kurios žiūrėjo sukneles, bet nepirko – specialų pasiūlymą su nuolaida.

Personalizacijos galimybės: „Omnisend” leidžia įterpti dinaminį turinį į SMS žinutes. Galite naudoti klientų vardus, paskutinių peržiūrėtų produktų pavadinimus, ar net specifines nuolaidas, apskaičiuotas pagal jų lojalumo lygį. Tai gali skambėti kaip smulkmena, bet personalizuotos žinutės konvertuoja žymiai geriau nei bendrinės.

A/B testavimas SMS kampanijose

Taip, galite testuoti ir SMS kampanijas. Nors tekstas ribotas (160 simbolių standartinei žinutei), vis tiek yra erdvės eksperimentams. Galite testuoti:

– Skirtingus call-to-action formatus
– Emoji naudojimą (arba jų nebuvimą)
– Skirtingus siuntimo laikus
– Trumpus vs ilgesnius tekstus
– Skirtingus pasiūlymus (10% nuolaida vs nemokamas pristatymas)

„Omnisend” turi integruotą A/B testavimo funkciją, kuri automatiškai paskirsto auditoriją ir matuoja rezultatus. Tai leidžia nuolat optimizuoti kampanijas ir gerinti ROI.

Techninis setup ir integracija su e-commerce platformomis

Jei naudojate „Shopify”, „WooCommerce”, „BigCommerce” ar kitą populiarią e-commerce platformą, integracija su „Omnisend” yra gana paprasta. Dauguma platformų turi oficialius „Omnisend” pluginus ar aplikacijas, kurias galima įdiegti per kelias minutes.

Po integracijos, „Omnisend” automatiškai sinchronizuoja jūsų klientų duomenis, užsakymus, produktus ir kitus svarbius duomenis. Tai reiškia, kad galite iš karto pradėti kurti segmentus ir kampanijas, paremtas realiomis duomenimis iš jūsų parduotuvės.

SMS sender ID konfigūracija: Kai siunčiate SMS, gavėjas mato siuntėjo ID – tai gali būti jūsų įmonės pavadinimas arba telefono numeris. „Omnisend” leidžia nustatyti custom sender ID, bet tai priklauso nuo šalies reguliacijų. Kai kuriose šalyse (pvz., JAV) dažnai naudojami short codes arba long codes, o Europoje dažniau galima naudoti alphanumeric sender ID.

Jei planuojate siųsti didelius kiekius SMS, verta apsvarstyti dedicated short code įsigijimą. Tai brangiau (gali kainuoti nuo kelių šimtų iki kelių tūkstančių dolerių per metus), bet suteikia geresnį pristatymą ir leidžia gauti atsakymus iš klientų.

API galimybės pažengusiems vartotojams

Jei turite savo custom sistemą arba norite gilesnės integracijos, „Omnisend” siūlo REST API. Per API galite:

– Programiškai pridėti kontaktus su telefono numeriais
– Trigger’inti SMS kampanijas pagal custom event’us
– Gauti kampanijų statistiką
– Valdyti segmentus ir workflow

Dokumentacija yra gana išsami, nors kartais trūksta konkrečių pavyzdžių. Jei esate developeris, tikėtina, kad per dieną-dvi galėsite susikurti reikiamą integraciją. API naudoja standartinę OAuth 2.0 autentifikaciją, todėl saugumo požiūriu viskas tvarkoje.

Kainodara ir ROI skaičiavimas

Kalbant apie pinigus – SMS marketingas nėra pigus, bet gali būti labai efektyvus. „Omnisend” SMS kainodara yra gana tipiška rinkai: mokate už platformos naudojimą (jei naudojate mokamą planą) plius papildomai už SMS kreditus.

SMS kreditų kainos:
– JAV: ~$0.015-0.02 per žinutę
– Kanada: ~$0.02-0.03
– JK: ~$0.04-0.06
– Kitos Europos šalys: ~$0.05-0.08
– Azija ir kitos šalys: labai skiriasi, bet vidutiniškai ~$0.03-0.10

Kaip apskaičiuoti, ar SMS kampanijos apsimoka? Paprastas būdas:


ROI = (Pajamos iš SMS kampanijų - SMS išlaidos) / SMS išlaidos × 100%

Pavyzdžiui, jei išleidote $200 SMS kampanijai (10,000 žinučių po $0.02) ir sugeneravote $2,000 papildomų pardavimų, jūsų ROI yra 900%. Tai puikus rezultatas.

Praktikoje, geri SMS kampanijų ROI rodikliai e-commerce sektoriuje yra:
– 300-500% – normalus rezultatas
– 500-1000% – geras rezultatas
– 1000%+ – puikus rezultatas

Žinoma, tai priklauso nuo daugelio faktorių: jūsų produktų kainų, auditorijos kokybės, žinučių turinio ir timing’o.

Kaip optimizuoti išlaidas

Keletas patarimų, kaip išlaikyti SMS marketingo išlaidas kontroliuojamas:

1. Naudokite SMS tik high-intent situacijose. Nebandykite pakeisti viso el. pašto marketingo SMS’ais. Naudokite SMS ten, kur jis tikrai prideda vertę – apleisti krepšeliai, skubūs pasiūlymai, užsakymų atnaujinimai.

2. Segmentuokite agresyviai. Geriau išsiųsti 1,000 žinučių labai tiksliniui segmentui, kuris konvertuos 5%, nei 10,000 žinučių plačiai auditorijai su 0.5% konversija.

3. Testuokite mažesniuose kiekiuose. Prieš siunčiant didelę kampaniją, išbandykite mažesniam segmentui. Taip išvengsite didelių nuostolių, jei kampanija neveikia.

4. Stebėkite opt-out rates. Jei žmonės masiškai atsisakinėja prenumeratos, tai signalas, kad siunčiate per daug arba netinkamą turinį. Geriau turėti mažesnį, bet įsitraukusį sąrašą.

Compliance ir teisiniai aspektai

SMS marketingas yra vienas labiausiai reguliuojamų marketingo kanalų. Skirtingose šalyse yra skirtingi reikalavimai, bet keletas bendrų principų:

GDPR (Europa): Privalomas aiškus opt-in. Negalite siųsti marketingo SMS be aiškaus sutikimo. Klientai turi turėti lengvą būdą atsisakyti prenumeratos. Privalote saugiai saugoti asmeninius duomenis.

TCPA (JAV): Reikalingas „prior express written consent” komercinėms žinutėms. Tai reiškia, kad klientas turi būti aktyviai sutikęs gauti SMS, ne tik pateikęs telefono numerį. Taip pat yra apribojimai dėl siuntimo laiko ir automatinių skambučių.

CASL (Kanada): Panašiai kaip GDPR, reikia aiškaus sutikimo. Taip pat privalote identifikuoti save kiekvienoje žinutėje ir suteikti opt-out mechanizmą.

„Omnisend” padeda laikytis šių reikalavimų, automatiškai tvarkydamas opt-out’us ir saugodamas sutikimo įrašus. Bet jūs vis tiek esate atsakingi už tai, kaip renkate telefono numerius ir kaip juos naudojate.

Praktinis patarimas: Pasikonsultuokite su teisininku, ypač jei planuojate siųsti SMS į kelias skirtingas šalis. Baudos už pažeidimus gali būti didelės – GDPR atveju iki 4% metinių pajamų arba €20 milijonų (kas didesnė).

Kas toliau: SMS marketingo ateitis ir jūsų pirmieji žingsniai

SMS marketingas niekur nedingsta. Priešingai, su RCS (Rich Communication Services) atsiradimu, SMS evoliucionuoja į daug galingesnį kanalą. RCS leidžia siųsti interaktyvias žinutes su nuotraukomis, mygtukais, carousel’ais – beveik kaip mini aplikacija žinutėje. „Omnisend” jau eksperimentuoja su RCS palaikymu, nors tai dar ne visiškai mainstream.

Kitas didelis trendas – AI-powered personalizacija. Įsivaizduokite sistemą, kuri automatiškai nusprendžia, kuriam klientui siųsti SMS, kokiu laiku ir su kokiu turiniu, remdamasi machine learning modeliais. Tai jau vyksta, ir „Omnisend” bei kitos platformos investuoja į tokias technologijas.

Jei dar nenaudojate SMS marketingo, štai kaip pradėti su „Omnisend”:

1. Pradėkite nuo strategijos. Neįjunkite SMS tik todėl, kad galite. Pagalvokite, kokiose situacijose SMS pridėtų realią vertę jūsų klientams. Galbūt tai bus tik apleisti krepšeliai ir užsakymų atnaujinimai – ir tai jau bus puiku.

2. Sukurkite opt-in procesą. Įdiekite registracijos formą su SMS sutikimu. Pasiūlykite kažką vertingo mainais – 10% nuolaidą, nemokamą pristatymą ar early access į naujus produktus.

3. Pradėkite nuo vieno workflow. Nesistenkite iš karto sukurti 10 skirtingų SMS kampanijų. Pradėkite nuo apleisto krepšelio serijos su viena SMS žinute. Išmokite, kaip veikia, optimizuokite, ir tik tada plėskitės.

4. Matuokite ir optimizuokite. Stebėkite ne tik click-through rates, bet ir realias konversijas bei ROI. SMS turėtų generuoti realias pajamas, ne tik metrikus.

5. Derinkite su kitais kanalais. SMS veikia geriausiai kartu su el. paštu, push pranešimais ir kitais kanalais. „Omnisend” stiprybė kaip tik yra omnichannel požiūris, todėl išnaudokite tai.

Galiausiai, nepamirškite, kad SMS – tai ne tik marketingo įrankis, bet ir komunikacijos kanalas. Kai klientas gauna jūsų žinutę, jis turėtų jaustis, kad tai vertinga informacija, o ne spam’as. Jei laikysitės šio principo, SMS marketingas su „Omnisend” gali tapti vienu efektyviausių jūsų marketingo kanalų.

Technologijos keičiasi, platformos evoliucionuoja, bet pagrindinis principas lieka tas pats: suteikite vertę klientui tinkamu laiku tinkamu kanalu. SMS su „Omnisend” duoda jums įrankius tai padaryti – dabar jūsų eilė juos išnaudoti protingai.

WordPress kaip headless CMS su REST API

by adminin E-komercija, Internetinės parduotuvėsLeave a Comment on WordPress kaip headless CMS su REST API

Kodėl apskritai kalbame apie headless architektūrą?

Prieš keletą metų mintis naudoti WordPress kaip headless CMS atrodė keistokai – tarsi bandytum važiuoti automobiliu atbulomis tik todėl, kad taip įdomiau. Bet dabar situacija pasikeitė kardinaliai. Frontendo frameworkai kaip React, Vue ar Next.js tapo tokia kasdienybe, kad tradicinis monolitinis WordPress su savo temomis ir PHP šablonais daugeliui kūrėjų pradeda atrodyti kaip dinozauras.

Headless CMS koncepcija paprasta – atskiri backend’ą (turinio valdymą) nuo frontend’o (turinio atvaizdavimo). WordPress tampa tiesiog duomenų šaltiniu, o kaip tuos duomenis pateiksi vartotojui – tavo reikalas. Gali būti React aplikacija, mobili programėlė, IoT įrenginys ar net keli skirtingi frontendai vienu metu.

Kas įdomiausia – WordPress jau seniai turi įmontuotą REST API. Nuo 4.7 versijos tai standartinė funkcionalybė, kurią galima naudoti iškart po instaliavimo. Nereikia jokių papildomų pluginų ar sudėtingų konfigūracijų. Tiesiog įjungi WordPress, ir tuoj pat gauni visiškai funkcionalų API endpointą.

REST API galimybės ir ką gauni iš dėžės

WordPress REST API yra tikrai solidus dalykas. Pagal nutylėjimą gauni prieigą prie visų pagrindinių turinio tipų – įrašų (posts), puslapių (pages), komentarų, taksonomijų, vartotojų ir net medijos failų. Bazinis endpoint’as yra /wp-json/wp/v2/, ir per jį gali pasiekti praktiškai viską.

Pavyzdžiui, norint gauti paskutinius 10 įrašų, tiesiog kreipiesi į:
https://tavo-svetaine.lt/wp-json/wp/v2/posts?per_page=10

Atsakymas bus JSON formatu su visais įrašo duomenimis – pavadinimu, turiniu, ištrauka, autorium, kategorijomis, žymomis, paveikslėliu ir dar krūva metaduomenų. API palaiko filtravimą, rūšiavimą, paiešką ir puslapiavimą. Galima filtruoti pagal kategoriją, autorių, datą, statusą ir kitus parametrus.

Kas tikrai patogu – API automatiškai grąžina ir papildomą informaciją apie užklausą. Response headeriai turi X-WP-Total (bendras įrašų skaičius) ir X-WP-TotalPages (puslapių skaičius), todėl pagination’ą įgyvendinti labai paprasta.

Autentifikacija irgi išspręsta keliais būdais. Paprasčiausiems atvejams užtenka cookie autentifikacijos, kuri veikia automatiškai, jei esi prisijungęs prie WordPress admin. Rimtesnėms aplikacijoms yra JWT (JSON Web Tokens) arba OAuth palaikymas per papildomus pluginus. Application passwords funkcionalumas, pridėtas WordPress 5.6 versijoje, leidžia generuoti specialius slaptažodžius API prieigai be pagrindinių kredencialų atskleidimo.

Custom post types ir kaip juos eksponuoti per API

Tikroji WordPress jėga slypi custom post types. Jei kuri bet kokį rimtesnį projektą, greičiausiai naudosi pasirinktinius turinio tipus – produktus, portfolio darbus, renginius, komandos narius ar ką nors kita. Gera žinia – juos eksponuoti per REST API yra trivialiai paprasta.

Kai registruoji custom post type, tiesiog pridedi 'show_in_rest' => true parametrą:


register_post_type('produktas', [
'public' => true,
'show_in_rest' => true,
'rest_base' => 'produktai',
'rest_controller_class' => 'WP_REST_Posts_Controller',
]);

Ir viskas – tavo produktai dabar prieinami per /wp-json/wp/v2/produktai. Parametras rest_base leidžia kontroliuoti, kaip atrodys endpoint’o URL, o rest_controller_class nusako, kokia logika bus naudojama duomenų apdorojimui.

Tas pats principas veikia ir su custom taxonomies. Jei turi savo kategorijų sistemą ar žymas, pridedi 'show_in_rest' => true, ir jos tampa prieinamos per API. Tai reiškia, kad gali filtruoti įrašus pagal savo taksonomijas taip pat lengvai kaip pagal standartinius WordPress kategorijas.

Custom fields ir ACF integracija

Čia prasideda tikrasis smagumas. Beveik kiekvienas WordPress projektas naudoja custom fields – papildomus laukus, kurie praturtina standartinį turinį. Populiariausias įrankis tam – Advanced Custom Fields (ACF) pluginas, kuris tapo faktiškai industrijos standartu.

ACF turi puikų REST API palaikymą. Nuo 5.x versijos galima įjungti custom fields eksponavimą per API tiesiog pažymint checkbox’ą field group nustatymuose. Kai tai padarai, visi tie laukai atsiranda API response’e po acf raktu.

Tarkime, turi produkto custom post type su ACF laukais – kaina, aprašymas, techninės specifikacijos. API atsakymas atrodys maždaug taip:


{
"id": 123,
"title": {"rendered": "Super produktas"},
"acf": {
"kaina": "99.99",
"aprasymas": "Detalus aprašymas...",
"specifikacijos": {
"svoris": "1.5kg",
"matmenys": "30x20x10cm"
}
}
}

Jei naudoji kitą custom fields sprendimą arba tiesiog WordPress natyvius meta fields, gali juos eksponuoti per register_meta() funkciją su 'show_in_rest' => true parametru. Tai suteikia pilną kontrolę, kokius duomenis nori atskleisti per API.

Saugumo aspektai ir kas gali nepavykti

Čia reikia būti atsargiems. Pagal nutylėjimą WordPress REST API yra gana atviras – bet kas gali skaityti publikuotą turinį be autentifikacijos. Tai normalu ir dažniausiai norima, bet kartais gali būti per daug.

Pirmas dalykas – API atskleidžia informaciją apie vartotojus. Endpoint’as /wp-json/wp/v2/users grąžina visų svetainės vartotojų sąrašą su jų username’ais. Tai potenciali saugumo spraga, ypač jei naudoji username’us prisijungimui. Sprendimas paprastas – išjungti users endpoint’ą neautentifikuotiems vartotojams:


add_filter('rest_endpoints', function($endpoints) {
if (!is_user_logged_in()) {
unset($endpoints['/wp/v2/users']);
unset($endpoints['/wp/v2/users/(?P[\d]+)']);
}
return $endpoints;
});

Antra problema – rate limiting. WordPress REST API pagal nutylėjimą neturi jokių apribojimų, kiek užklausų gali padaryti. Tai reiškia, kad kažkas gali lengvai „užspaminti” tavo serverį. Yra pluginų, kurie sprendžia šią problemą (pvz., WP REST API Controller), arba gali implementuoti savo rate limiting logiką.

Trečias aspektas – CORS (Cross-Origin Resource Sharing). Jei tavo frontend’as yra kitame domene nei WordPress, naršyklė blokuos API užklausas. Reikia pridėti CORS headerius:


add_action('rest_api_init', function() {
remove_filter('rest_pre_serve_request', 'rest_send_cors_headers');
add_filter('rest_pre_serve_request', function($value) {
header('Access-Control-Allow-Origin: https://tavo-frontend.lt');
header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE');
header('Access-Control-Allow-Credentials: true');
return $value;
});
}, 15);

Performance optimizacija ir caching strategijos

WordPress nėra greičiausias dalykas pasaulyje, o kai naudoji jį kaip headless CMS, performance tampa dar svarbesnis. Kiekviena API užklausa reiškia PHP procesą, duomenų bazės queries ir visą WordPress bootstrap procesą.

Pirmasis žingsnis – įsitikinti, kad naudoji normalų hosting’ą su PHP 8.x ir OPcache. Tai skamba savaime suprantama, bet nustebsi, kiek projektų vis dar veikia ant PHP 7.2 ar net senesnių versijų. PHP 8.x duoda realų performance boost’ą.

Antra – object caching. WordPress turi įmontuotą object cache sistemą, bet pagal nutylėjimą ji veikia tik vieno request’o metu. Reikia persistent object cache – Redis arba Memcached. Su Redis ir tinkamu caching pluginu (pvz., Redis Object Cache) API response laikas gali sumažėti 3-5 kartus.

Trečia – HTTP caching. REST API response’ai turėtų turėti tinkamus cache headerius. Galima naudoti CDN kaip Cloudflare ar Fastly, kurie cache’ins API atsakymus. Arba implementuoti serverio lygio cache’inimą su Nginx ar Varnish.

Ketvirta – optimizuoti pačias užklausas. Jei nereikia viso įrašo turinio, naudok _fields parametrą, kad gautum tik tai, ko reikia:

/wp-json/wp/v2/posts?_fields=id,title,excerpt,featured_media

Tai gerokai sumažina response dydį ir duomenų bazės apkrovą. Taip pat verta pagalvoti apie duomenų bazės indeksus, ypač jei darai sudėtingas užklausas su meta queries ar taksonomijų filtravimą.

Praktiniai patarimai darbui su Next.js ir React

Jei kuri frontend’ą su React ar Next.js (o greičiausiai taip ir yra), yra keletas dalykų, kurie labai palengvina gyvenimą. Pirma – naudok kokią nors data fetching biblioteką. SWR arba React Query yra puikūs pasirinkimai, nes jie automatiškai tvarko cache’inimą, revalidation’ą ir loading states.

Su Next.js galima išnaudoti Static Site Generation (SSG) arba Incremental Static Regeneration (ISR). Tai reiškia, kad puslapiai generuojami build metu arba pirmojo request’o metu, o paskui cache’inami. Rezultatas – bliksiškai greitas website’as, nors backend’as ir būtų lėtokas WordPress.

Štai paprastas pavyzdys, kaip fetch’inti WordPress įrašus Next.js su ISR:


export async function getStaticProps() {
const res = await fetch('https://tavo-wp.lt/wp-json/wp/v2/posts');
const posts = await res.json();

return {
props: { posts },
revalidate: 60 // Regeneruoti kas 60 sekundžių
};
}

Dėl images – WordPress media library turi visas reikalingas image sizes ir meta informaciją. API grąžina media_details objektą su visais available sizes. Galima naudoti Next.js Image komponentą su WordPress sugeneruotais images, arba implementuoti custom image optimization su Cloudinary ar imgix.

Dar vienas patarimas – naudok TypeScript ir sugeneruok types iš WordPress schema. Yra įrankių kaip openapi-typescript, kurie gali sugeneruoti TypeScript interfaces iš REST API schema endpoint’o (/wp-json). Tai išgelbės nuo daugelio klaidų ir padarys development’ą daug malonesnį.

Kai WordPress REST API nepakanka ir ką daryti toliau

Kartais REST API tiesiog nepakanka. Jei reikia labai sudėtingų užklausų, daug related duomenų arba tiesiog norisi modernesnio API stiliaus, verta pažvelgti į GraphQL. WPGraphQL pluginas yra nuostabus sprendimas, kuris transformuoja WordPress į pilnavertį GraphQL serverį.

GraphQL privalumas – gauni tiksliai tuos duomenis, kurių reikia, viena užklausa. Jei reikia įrašo su autoriaus informacija, featured image, kategorijomis ir related posts, REST API reikėtų padaryti kelis request’us. Su GraphQL – vieną.

Kitas scenarijus – real-time funkcionalumas. REST API yra request-response modelis, todėl real-time updates reikalauja polling’o arba webhook’ų. Jei kuri aplikaciją, kur reikia live updates (pvz., komentarų sistemą ar collaborative editing), gali reikėti papildomų sprendimų kaip WebSockets ar Server-Sent Events.

Taip pat verta pagalvoti apie content preview funkcionalumą. Kai redaktoriai kuria turinį WordPress admin’e, jie nori matyti, kaip jis atrodys frontend’e prieš publikuojant. Su headless setup’u tai nėra automatiškai. Reikia implementuoti preview mode – Next.js turi tam puikų palaikymą su Preview Mode API, bet reikia papildomo kodo WordPress pusėje.

Dėl deployment’o – headless WordPress setup’as dažniausiai reiškia du atskirus serverius: vieną WordPress backend’ui, kitą frontend’ui. Tai suteikia lankstumą, bet ir prideda kompleksiškumo. Frontend’ą gali host’inti Vercel, Netlify ar panašiose platformose, o WordPress – specializuotame WP hosting’e kaip Kinsta ar WP Engine.

Galiausiai, jei projektas auga, gali prireikti content delivery optimizacijos. Webhook’ai, kurie trigger’ina frontend rebuild’ą kai turinys pasikeičia WordPress’e. Build cache’inimas, kad rebuild’ai būtų greitesni. Partial builds, kad nereikėtų rebuild’inti viso site’o kiekvieną kartą. Visa tai įmanoma, bet reikalauja planavimo ir papildomo darbo.

Headless WordPress su REST API nėra silver bullet, bet tai tikrai galingas įrankis tinkamose situacijose. Gauni patikimą, gerai pažįstamą turinio valdymo sistemą su puikia admin sąsaja, kurią redaktoriai jau moka naudoti. Tuo pačiu išlaisvi frontend’ą naudoti modernius frameworkus ir architektūras. Jei projektas to reikalauja – verta bandyti, tik būk pasirengęs papildomam kompleksiškumui ir infrastruktūros valdymui.

„Amazon SES” e-pašto siuntimo paslauga

by adminin Hostingas / svetainių talpinimasLeave a Comment on „Amazon SES” e-pašto siuntimo paslauga

Kas ta Amazon SES ir kodėl ji turėtų rūpėti

Jei kada nors bandėte siųsti didelius kiekius el. laiškų tiesiogiai iš savo serverio, turbūt pastebėjote, kad tai ne taip paprasta kaip atrodo. Jūsų laiškai keliauja tiesiai į spam aplanką, IP adresai patenka į juoduosius sąrašus, o pristatymo rodikliai primena loteriją. Štai čia ir ateina į pagalbą Amazon Simple Email Service (SES) – AWS ekosistemos dalis, skirta profesionaliam el. pašto siuntimui.

Amazon SES yra debesų pagrindo el. pašto siuntimo platforma, kuri leidžia siųsti transakcines žinutes, marketingo kampanijas ir bet kokio kito tipo el. laiškus be galvos skausmo dėl infrastruktūros valdymo. Paslauga veikia nuo 2011 metų ir per tą laiką tapo vienu iš populiariausių sprendimų tarp kūrėjų.

Kas ją išskiria? Visų pirma – kaina. Mokate tik už tai, ką naudojate, be jokių mėnesinių mokesčių ar minimumų. Pirmi 62,000 laiškų per mėnesį yra visiškai nemokami, jei siunčiate iš EC2 instancijos. Po to kaina siekia vos $0.10 už 1,000 laiškų. Palyginkite su kitais sprendimais rinkoje – skirtumas akivaizdus.

Kaip pradėti: nuo smėlio dėžės iki gamybos

Pradedant su SES, pirmiausia susiduriate su sandbox režimu. Tai AWS saugumo mechanizmas, kuris neleidžia spamerinėms veikloms. Sandbox aplinkoje galite siųsti tik į patvirtintus el. pašto adresus ir turite 200 laiškų per dieną limitą. Skamba ribojančiai, bet tai protinga apsauga.

Norint išeiti iš sandbox, reikia pateikti prašymą AWS palaikymo komandai. Čia svarbu būti konkrečiam: paaiškinkite, kokio tipo laiškus siųsite, kaip tvarkote atsisakymus (unsubscribe), kaip valdote skundus. AWS tikrai skaito šiuos prašymus, todėl neverta rašyti šabloniškų atsakymų. Paprastai sprendimas priimamas per 24 valandas, nors kartais gali užtrukti ilgiau.

Kai jau išeinate iš sandbox, vis tiek turite „warm-up” procesą. Negalite iš karto pradėti siųsti milijonų laiškų – tai pakels raudonas vėliavėles tiek AWS sistemose, tiek pas el. pašto teikėjus. Pradėkite nuo kelių tūkstančių per dieną ir palaipsniui didinkite apimtis. Stebėkite bounce ir complaint rates – jei jie viršija atitinkamai 5% ir 0.1%, jūsų paskyra gali būti sustabdyta.

Domeno ir el. pašto adresų autentifikavimas

Čia prasideda tikrasis darbas. Norint, kad jūsų laiškai pasiektų gavėjų inbox, o ne spam aplanką, privalote tinkamai sukonfigūruoti domeno autentifikaciją. SES palaiko tris pagrindinius standartus: SPF, DKIM ir DMARC.

DKIM (DomainKeys Identified Mail) yra svarbiausias iš jų. SES automatiškai sugeneruoja DKIM rakto porą, o jums reikia tik pridėti CNAME įrašus į savo DNS zoną. Tai užtikrina, kad jūsų laiškai yra autentiški ir nebuvo pakeisti kelyje. AWS konsolėje rasite tikslias reikšmes – tiesiog nukopijuokite jas į savo DNS valdymo sąsają.

SPF (Sender Policy Framework) įrašas nurodo, kurie serveriai gali siųsti laiškus jūsų domeno vardu. SES dokumentacijoje rasite rekomenduojamą SPF įrašą, kuris paprastai atrodo maždaug taip: `v=spf1 include:amazonses.com ~all`. Jei jau turite SPF įrašą, tiesiog pridėkite amazonses.com include direktyvą.

DMARC politika nusako, kaip el. pašto teikėjai turėtų elgtis su laiškais, kurie nepraėjo SPF ar DKIM patikrinimų. Pradedantiesiems rekomenduoju nustatyti `p=none` su raportavimo adresu – taip galėsite stebėti, kas vyksta, neprarasdami laiškų. Vėliau galite sugriežtinti iki `p=quarantine` ar net `p=reject`.

Integracija su aplikacija: SMTP vs API

SES siūlo du pagrindinius būdus siųsti laiškus: SMTP sąsają ir API. Kiekvienas turi savo privalumų, priklausomai nuo jūsų situacijos.

SMTP metodas puikiai tinka, kai turite esamą aplikaciją, kuri jau naudoja SMTP protokolą. Daugelis CMS sistemų, el. pašto klientų ir programinės įrangos palaiko SMTP iš dėžės. Tiesiog pakeičiate SMTP serverio nustatymus į SES endpoint’ą, pridedate kredencialus (ne savo AWS root kredencialus, dieve mano, bet specialiai sugeneruotus SMTP kredencialus), ir viskas veikia. Endpoint’ai skiriasi pagal regioną, pavyzdžiui: `email-smtp.eu-west-1.amazonaws.com`.

API metodas suteikia daugiau kontrolės ir funkcionalumo. Galite naudoti AWS SDK beveik bet kuriai programavimo kalbai – Python boto3, JavaScript AWS SDK, PHP SDK ir t.t. API leidžia lengviau valdyti šablonus, konfigūruoti configuration sets, gauti detalesnius atsakymus apie siuntimo būseną.

Štai paprastas Python pavyzdys:

„`python
import boto3

ses = boto3.client(‘ses’, region_name=’eu-west-1′)

response = ses.send_email(
Source=’[email protected]’,
Destination={‘ToAddresses’: [‘[email protected]’]},
Message={
‘Subject’: {‘Data’: ‘Testas’, ‘Charset’: ‘UTF-8’},
‘Body’: {‘Text’: {‘Data’: ‘Turinys’, ‘Charset’: ‘UTF-8’}}
}
)
„`

Asmeniškai rekomenduoju API metodą naujiems projektams – jis lankstesnis ir leidžia išnaudoti visas SES galimybes.

Configuration Sets ir siuntimo analizė

Configuration Sets yra viena iš galingiausių SES funkcijų, kurią daugelis nepakankamai išnaudoja. Tai leidžia grupuoti siuntimus, stebėti metrikas ir nukreipti įvykius į kitus AWS servisus.

Sukūrus configuration set, galite pridėti event destinations – kur SES siųs informaciją apie įvykius. Pavyzdžiui, galite nukreipti visus bounce, complaint, delivery, send, reject, open ir click įvykius į CloudWatch, Kinesis Firehose ar SNS. Tai neįkainojama informacija optimizuojant el. pašto kampanijas.

CloudWatch metrikose galite stebėti:
– Delivery rate – kiek laiškų sėkmingai pristatyta
– Bounce rate – kiek grįžo atgal (hard vs soft bounces)
– Complaint rate – kiek gavėjų pažymėjo kaip spam
– Open rate ir click rate (jei įjungtas tracking)

Praktinis patarimas: sukurkite atskirą configuration set kiekvienam laiškų tipui (transakcinis, marketingas, pranešimai). Taip galėsite tiksliau analizuoti, kurie laiškai veikia geriau, ir greitai identifikuoti problemas.

Bounce ir complaint valdymas yra kritiškai svarbus. SES automatiškai tvarko hard bounces – jei el. pašto adresas neegzistuoja, jis nebus bandomas siųsti dar kartą. Tačiau jūs turite įgyvendinti logiką, kuri pašalina tokius adresus iš savo duomenų bazės. Ignoravimas gali baigtis paskyros sustabdymu.

Šablonai ir personalizavimas

SES palaiko el. laiškų šablonus, kurie leidžia atskirti turinį nuo logikos. Galite sukurti šabloną su kintamaisiais, o siųsdami tiesiog perduoti reikšmes. Tai ypač patogu transakciniams laiškams – registracijos patvirtinimas, slaptažodžio atstatymas, sąskaitų siuntimas.

Šablonai kuriami JSON formatu ir gali turėti tiek HTML, tiek text versijas. Štai supaprastintas pavyzdys:

„`json
{
„TemplateName”: „Pasveikinimas”,
„SubjectPart”: „Sveiki, {{vardas}}!”,
„HtmlPart”: „

Labas, {{vardas}}

Ačiū už registraciją {{data}}.

„,
„TextPart”: „Labas, {{vardas}}\n\nAčiū už registraciją {{data}}.”
}
„`

Siųsdami laišką su šablonu, tiesiog nurodote šablono pavadinimą ir perduodate kintamųjų reikšmes. SES automatiškai sugeneruoja galutinį laišką.

Dėl personalizavimo – būkite atsargūs su dinaminiu turiniu. Jei kiekvienas laiškas yra unikalus, negalėsite pasinaudoti batch siuntimo efektyvumu. Kartais geriau siųsti šiek tiek mažiau personalizuotą laišką, bet greitai ir patikimai, nei laukti valandų, kol sugeneruojami tūkstančiai unikalių variantų.

Kainodara ir optimizavimas

Jau minėjau, kad SES yra pigus, bet verta pasigilinti į detales. Bazinė kaina – $0.10 už 1,000 laiškų. Tačiau yra papildomų išlaidų:
– Priedai: $0.12 už GB
– Dedicated IP adresai: $24.95 per mėnesį už IP
– Gaunami laiškai: $0.10 už 1,000 laiškų

Dedicated IP adresai verta investuoti tik jei siunčiate didelius kiekius (bent 50,000+ per dieną) ir norite kontroliuoti savo reputaciją. Mažesnėms apimtims shared IP pool’as veikia puikiai – AWS palaiko gerą reputaciją, o jūs nemokamai naudojatės tuo.

Jei siunčiate labai didelius kiekius, apsvarstykite Kinesis Firehose naudojimą event’ams vietoj CloudWatch – tai gali būti pigiau. Taip pat, jei jums nereikia open ir click tracking, išjunkite juos – tai sumažina duomenų kiekį ir šiek tiek pagerina pristatymo greitį.

Dar vienas optimizavimo būdas – naudoti bulk siuntimo operacijas. SendBulkTemplatedEmail API leidžia siųsti iki 50 laiškų vienu užklausos, kas sumažina API iškvietimų skaičių ir šiek tiek pagreitina procesą.

Dažniausios problemos ir jų sprendimai

Per metus darbo su SES, susidūriau su įvairiomis problemomis. Štai dažniausios ir kaip jas spręsti.

**”Throttling” klaidos** – SES turi siuntimo limitus, kurie priklauso nuo jūsų paskyros istorijos. Pradžioje galite siųsti tik kelis laiškus per sekundę. Sprendimas: įgyvendinkite retry logiką su exponential backoff. AWS SDK dažniausiai tai daro automatiškai, bet jei naudojate SMTP, reikia patiems pasirūpinti.

**Aukštas bounce rate** – jei viršijate 5%, AWS gali sustabdyti siuntimą. Priežastys: prasta el. pašto adresų kokybė, pirkti sąrašai, seni duomenys. Sprendimas: įgyvendinkite double opt-in, reguliariai valykite sąrašus, naudokite el. pašto validacijos servisus prieš pridedant adresus į DB.

**Laiškai patenka į spam** – net su tinkamu DKIM/SPF. Priežastys: prastas turinys, per daug nuorodų, spam trigger žodžiai, žemas engagement. Sprendimas: testuokite laiškus su Mail Tester ar panašiais įrankiais, vengkite agresyvaus marketingo kalbos, įtraukite aiškų unsubscribe mechanizmą.

**Lėtas pristatymas** – laiškai pasiekia gavėjus po kelių minučių ar valandų. Priežastys: gavėjo serverio greylisting, jūsų siuntimo greitis per mažas, regionas per toli. Sprendimas: pasirinkite SES regioną arčiau jūsų auditorijos, padidinkite siuntimo greitį (jei leidžia limitai), naudokite dedicated IP su gera reputacija.

**Complaint rate per aukštas** – žmonės žymi jūsų laiškus kaip spam. Priežastys: siunčiate tiems, kas neprašė, per dažnai siunčiate, turinys neatitinka lūkesčių. Sprendimas: gerbkite savo prenumeratorius, leiskite lengvai atsisakyti, siųskite tik tai, ko žmonės tikisi.

Kai viskas veikia ir ką daryti toliau

Kai jūsų SES infrastruktūra veikia sklandžiai, atėjo laikas galvoti apie tolesnius žingsnius. Pirmiausia – monitoring ir alerting. Sukonfigūruokite CloudWatch alarms bounce ir complaint rate metrikoms. Jei rodikliai viršija saugius ribas, turėtumėte gauti pranešimą iš karto, o ne sužinoti iš AWS email’o, kad jūsų paskyra sustabdyta.

Apsvarstykite feedback loop’ų integraciją. Kai kas nors pažymi jūsų laišką kaip spam, SES gali siųsti notification. Automatiškai pašalinkite tokius vartotojus iš siuntimo sąrašų – tai apsaugos jūsų reputaciją ir sutaupys pinigų.

Jei jūsų verslas auga, verta pagalvoti apie multi-region setup’ą. SES veikia regionuose nepriklausomai, todėl galite turėti failover mechanizmą. Jei viename regione iškyla problemų, automatiškai perjunkite į kitą. Tai ypač svarbu, jei el. paštas yra kritinė jūsų verslo dalis.

Testavimas turėtų būti nuolatinis procesas. Reguliariai siųskite test laiškus į skirtingus el. pašto teikėjus (Gmail, Outlook, Yahoo, Apple Mail) ir tikrinkite, kaip jie atrodo, ar nepatenka į spam. El. pašto teikėjai nuolat keičia savo algoritmus, todėl tai, kas veikė prieš mėnesį, gali nebeveikti dabar.

Dokumentuokite savo setup’ą. Kai po metų reikės pakeisti kažką DNS įrašuose ar pridėti naują domeną, būsite dėkingi sau už aiškius užrašus. Įtraukite visus DNS įrašus, configuration sets, IAM roles, event destinations – visa, kas susiję su SES.

Ir paskutinis, bet ne mažiau svarbus dalykas – sekite AWS SES blog’ą ir changelog’us. AWS reguliariai prideda naujas funkcijas, pagerina esamas, kartais keičia pricing. Pavyzdžiui, neseniai pridėjo Virtual Deliverability Manager, kuris padeda optimizuoti pristatymo rodiklius. Tokios funkcijos gali reikšmingai pagerinti jūsų rezultatus, bet apie jas reikia žinoti.

SES nėra „set and forget” sprendimas – tai įrankis, kuris reikalauja nuolatinės priežiūros ir optimizavimo. Bet jei viską darote teisingai, gausite patikimą, pigią ir masteliuojamą el. pašto infrastruktūrą, kuri tarnaus jums daugelį metų.

„HubSpot” automatizavimo galimybės vidutinėms įmonėms

by adminin E-komercijaLeave a Comment on „HubSpot” automatizavimo galimybės vidutinėms įmonėms

Kodėl automatizavimas tapo ne prabanga, o būtinybe

Prisimenu laikus, kai CRM sistemą turėti buvo tarsi statusas – kažkas, kuo galėjo pasigirti tik stambiosios kompanijos su ištisais IT departamentais. Dabar situacija kardinaliai pasikeitė. Vidutinės įmonės, turinčios 50-200 darbuotojų, susiduria su paradoksu: klientų bazė auga, procesai komplikuojasi, bet resursų papildomam personalui vis tiek trūksta. Čia ir ateina į pagalbą automatizavimas.

„HubSpot” platformą esu matęs įvairiausių dydžių įmonėse, bet būtent vidutinio verslo segmente ji atsiskleidžia geriausiai. Kodėl? Nes čia jau yra ko automatizuoti, bet dar nėra tokios biurokratijos kaip korporacijose, kur kiekvienas pakeitimas turi praeiti per penkis derinimo etapus. Vidutinės įmonės yra pakankamai lanksčios, kad greitai įdiegtų naujoves, bet pakankamai brandžios, kad suprastų, jog rankinis duomenų perkėlinėjimas iš vienos sistemos į kitą – tai praėjusio amžiaus reliktai.

Pardavimų procesų automatizavimas: daugiau nei tik el. laiškų siuntimas

Kai kalbame apie pardavimų automatizavimą, dažnai žmonės įsivaizduoja tik automatines el. laiškų sekas. Tai tarsi manyti, kad automobilis – tai tik keturi ratai. „HubSpot” pardavimų automatizacija prasideda nuo lead’ų valdymo ir baigiasi sandorių uždarymu bei klientų perdavimu aptarnavimo komandai.

Praktiškai tai atrodo taip: potencialus klientas užpildo formą jūsų svetainėje. Sistema automatiškai priskiria jį atitinkamam pardavimų vadybininkui pagal geografiją, pramonės šaką ar bet kokius kitus kriterijus, kuriuos nustatėte. Vadybininkas gauna pranešimą, o lead’as automatiškai įtraukiamas į auginimo (nurturing) seką. Jei per savaitę niekas nesusisiekia, sistema siunčia priminimą vadybininkui. Jei lead’as atidaro el. laišką tris kartus ir apsilanko puslapyje su kainomis – prioritetas automatiškai pakyla.

Vienas iš galingiausių įrankių, kurį dažnai nepakankamai išnaudoja – tai lead scoring. „HubSpot” leidžia sukurti sudėtingas balų sistemas, kurios vertina ne tik veiksmus (puslapio apsilankymai, el. laiškų atidarymai), bet ir demografinius duomenis. Pavyzdžiui, jei jūsų idealus klientas yra 100+ darbuotojų įmonė iš gamybos sektoriaus, sistema automatiškai suteiks daugiau balų tokiems lead’ams.

Marketingo automatizacija: kai kampanijos veikia ir jums miegant

Marketingo automatizacija „HubSpot” platformoje – tai vieta, kur sistema tikrai spindi. Workflow’ai čia gali būti nuo paprastų (atsiuntė naują el. laišką visiems, kas atsisiuntė e-knygą) iki neįtikėtinai sudėtingų, su daugybe šakojimų ir sąlygų.

Realus pavyzdys iš praktikos: įmonė, parduodanti B2B programinę įrangą, sukūrė workflow’ą, kuris automatiškai segmentuoja lead’us pagal jų elgesį. Jei lead’as žiūri techninius straipsnius ir dokumentaciją – jis nukreipiamas į techninę seką su daugiau detalių. Jei domisi ROI skaičiuoklėmis ir atvejų studijomis – gauna verslo orientuotą turinį. Sistema taip pat automatiškai stebi engagement’ą ir, jei pastebimas aktyvumo kritimas, perjungia į reaktyvavimo kampaniją.

Ypač naudinga yra galimybė automatizuoti socialinių tinklų publikacijas. Galite suplanuoti visą mėnesio turinį, ir sistema ne tik publikuos nustatytu laiku, bet ir automatiškai stebės rezultatus. Jei pastebimas ypač geras engagement’as tam tikro tipo įrašuose, galite sukurti workflow’ą, kuris automatiškai siūlo panašų turinį.

Klientų aptarnavimo automatizacija: greičiau reaguoti, geriau aptarnauti

Klientų aptarnavimas – tai sritis, kur automatizavimas dažnai sulaukia skepticizmo. „Ar klientai nenori bendrauti su gyvais žmonėmis?” Žinoma, nori. Bet jie dar labiau nori greitų atsakymų ir efektyvaus problemų sprendimo. Ir čia automatizavimas ne pakeičia žmones, o leidžia jiems dirbti efektyviau.

„HubSpot” Service Hub leidžia sukurti automatines ticketing sistemas, kurios ne tik priskiria užklausas atitinkamiems specialistams, bet ir nustato prioritetus pagal kliento vertę, problemos pobūdį ar sutarties sąlygas. Premium klientas su kritine problema automatiškai gauna aukščiausią prioritetą ir priskiriamas senior specialistui.

Chatbot’ai čia irgi vaidina svarbų vaidmenį. Ne, jie neturi atsakyti į visus klausimus. Bet jie puikiai tinka pradinei informacijai surinkti, dažniausiai užduodamiems klausimams atsakyti ir nukreipti klientą tinkama kryptimi. Pavyzdžiui, jei klientas klausia apie sąskaitos būseną, bot’as gali automatiškai patikrinti sistemoje ir pateikti atsakymą. Jei problema sudėtingesnė – surinkti pradinę informaciją ir sukurti ticket’ą su visa kontekstine informacija.

Ataskaitų ir analitikos automatizavimas: duomenys, kurie patys ateina pas jus

Vienas iš didžiausių laiko ėdikų bet kurioje įmonėje – tai ataskaitų rengimas. Vadovai nori matyti skaičius, skyrių vadovai nori stebėti komandos rezultatus, o pardavimų vadybininkai – savo pipeline’ą. Tradiciškai tai reiškė valandas praleidžiant Excel’yje, bandant sujungti duomenis iš skirtingų šaltinių.

„HubSpot” leidžia automatizuoti visą šį procesą. Galite sukurti custom dashboard’us skirtingiems vaidmenims ir nustatyti, kad ataskaitos būtų automatiškai siunčiamos el. paštu kas savaitę ar mėnesį. Dar geriau – galite nustatyti automatines alert’us, kai tam tikri rodikliai pasiekia kritines reikšmes. Pavyzdžiui, jei konversijos rodiklis nukrenta žemiau tam tikro lygio, atsakingas asmuo automatiškai gauna pranešimą.

Ypač naudinga yra galimybė automatizuoti attribution reporting. Sistema automatiškai seka, kurie marketingo kanalai generuoja geriausius lead’us ir kokia yra jų kelionė iki sandorio užbaigimo. Tai leidžia priimti duomenimis pagrįstus sprendimus apie marketingo biudžeto paskirstymą.

Integracijų automatizavimas: kai visos sistemos kalba viena kalba

Vidutinės įmonės paprastai naudoja ne vieną, o keliolika skirtingų sistemų: CRM, apskaitos programą, projektų valdymo įrankius, komunikacijos platformas. Problema atsiranda tada, kai šios sistemos nekalba tarpusavyje, ir duomenis tenka perkelti rankiniu būdu.

„HubSpot” turi integracijas su šimtais populiarių platformų, ir dauguma jų gali būti automatizuotos. Pavyzdžiui, kai sandoris pažymimas kaip laimėtas „HubSpot”, automatiškai sukuriamas projektas „Asana” ar „Monday.com”, sukuriama sąskaita apskaitos sistemoje, o klientas pridedamas į Slack kanalą.

Jei reikalingos specifinės integracijos, kurioms nėra ready-made sprendimų, galima naudoti „Zapier” ar „Make” (buvęs „Integromat”). Šios platformos veikia kaip tarpininkai tarp „HubSpot” ir praktiškai bet kurios kitos sistemos. Pavyzdžiui, galite automatizuoti procesą, kai naujas lead’as „HubSpot” automatiškai sukuria eilutę Google Sheets, siunčia pranešimą į Teams ir prideda užduotį į „Trello”.

Svarbu paminėti API galimybes. Jei turite savo custom sistemų ar specifinių poreikių, „HubSpot” API yra pakankamai galingas ir gerai dokumentuotas, kad galėtumėte sukurti bet kokias integracijas. Esu matęs įmones, kurios automatizavo viską – nuo sandėlio valdymo sistemos sujungimo su CRM iki automatinio klientų segmentavimo pagal duomenis iš išorinių duomenų bazių.

Praktiniai patarimai įdiegiant automatizavimą

Dabar pereikime prie to, kaip realiai pradėti. Didžiausia klaida, kurią matau – tai bandymas automatizuoti viską iš karto. Rezultatas – chaosas, neveikiantys workflow’ai ir frustruota komanda. Geriau pradėti nuo mažų, bet konkrečių dalykų.

Pradėkite nuo skausmo taškų. Pasikalbėkite su komanda ir išsiaiškinkite, kokie procesai labiausiai erzina, kur daugiausia laiko švaistomos. Galbūt tai nuolatinis duomenų perkėlinėjimas tarp sistemų? Ar gal vadybininkai pamiršta sekti lead’us? Būtent šias problemas ir automatizuokite pirmiausia.

Dokumentuokite procesus prieš automatizuodami. Skamba nuobodžiai, bet tai kritiškai svarbu. Jei neturite aiškaus proceso aprašymo, kaip galite jį automatizuoti? Išsibrėžkite flowchart’ą – kas vyksta, kokios sąlygos, kokie sprendimai priimami. Tik tada verčiate tai į workflow’us.

Testuokite su mažomis grupėmis. Prieš įjungdami automatizavimą visai klientų bazei, išbandykite su nedidele grupe. Tai leidžia pastebėti klaidas ir nelogiškumus, kol dar nėra per vėlu. Pavyzdžiui, galite sukurti testinį workflow’ą ir paleisti jį su 50 lead’ų, stebėdami rezultatus savaitę.

Nustatykite aiškias metricas. Kaip žinosite, ar automatizavimas veikia? Turite turėti konkrečius rodiklius. Pavyzdžiui, jei automatizuojate lead’ų auginimą, stebėkite konversijos rodiklį, engagement’o lygį, laiką iki sandorio. Jei skaičiai gerėja – einate teisinga kryptimi.

Nepamirškite žmogiškojo faktoriaus. Automatizavimas neturi pašalinti asmeninio prisilietimo. Geriausi rezultatai pasiekiami derinant automatizavimą su asmeniniu bendravimu. Pavyzdžiui, automatinė el. laiškų seka gali šildyti lead’ą, bet kritiniame momente turėtų įsikišti gyvas pardavimų vadybininkas.

Kai automatizavimas tampa konkurenciniu pranašumu

Grįžtant prie esmės – „HubSpot” automatizavimo galimybės vidutinėms įmonėms yra ne tik efektyvumo įrankis, bet ir strateginis pranašumas. Kai jūsų konkurentai vis dar rankiniu būdu valdo lead’us ir siunčia el. laiškus, jūs galite aptarnauti tris kartus daugiau klientų su ta pačia komanda.

Svarbu suprasti, kad automatizavimas – tai ne vienkartinis projektas, o nuolatinis procesas. Rinka keičiasi, klientų elgsena keičiasi, jūsų verslas auga. Tai reiškia, kad workflow’ai turi būti reguliariai peržiūrimi ir optimizuojami. Rekomenduoju kas ketvirtį skirti dieną workflow’ų auditui – kas veikia gerai, kas ne, ką galima pagerinti.

Kitas aspektas – komandos mokymas. Geriausia automatizavimo sistema nieko neverta, jei komanda nemoka ja naudotis arba bijo. Investuokite į mokymą, sukurkite vidinę dokumentaciją, paskatinkite eksperimentavimą. Leiskite komandai patiems kurti paprastus workflow’us – tai ne tik sumažina IT departamento naštą, bet ir didina įsitraukimą.

Galiausiai, nepamirškite, kad automatizavimas turi tarnauti verslo tikslams, o ne atvirkščiai. Kartais matau įmones, kurios automatizuoja procesus tik todėl, kad gali, neatsižvelgdamos į realią naudą. Kiekvienas workflow’as turėtų turėti aiškų verslo pagrindimą ir matuojamą poveikį rezultatams. Jei automatizavimas nesukuria vertės – greičiausiai jis nereikalingas.

Vidutinėms įmonėms „HubSpot” siūlo idealų balansą tarp galimybių ir paprastumo. Jums nereikia armijos IT specialistų, kad sukurtumėte sudėtingus workflow’us, bet turite pakankamai galios, kad automatizuotumėte beveik bet ką. Pradėkite nuo mažų žingsnių, mokykitės iš klaidų ir nuolat tobulėkite. Per metus jūsų komanda dirbs efektyviau, klientai bus laimingesni, o jūs turėsite daugiau laiko strateginiams dalykams vietoj rutinos.