Ce ar trebui să știți despre CMS ca manager CRM?

Sunteți manager CRM, marketer, manager de produs sau, cu alte cuvinte, o persoană non-tech, vă întrebați ce este CMS și ce ar trebui să știți despre el? Sunteți deja utilizator CMS, dar doriți să obțineți mai multe cunoștințe tehnice despre platformă? Te gândești să-ți schimbi CMS-ul, dar să scrii un RFP despre ceva despre care nu ai nici cea mai mică idee te sperie? Vă mutați într-o poziție nouă sau obțineți noi sarcini și va trebui să lucrați mai îndeaproape cu dezvoltatorii CMS?

Nu vă supărați, conceptele tehnice din jurul platformelor CMS sunt destul de simple și, ca persoană netehnică, de obicei nu trebuie să le cunoașteți atât de mult în detaliu. Cel mai important lucru este să înțelegeți câteva definiții de bază, să înțelegeți platforma pe care o folosește compania dvs. și să cunoașteți câteva cuvinte de bază. Mai târziu, dacă aveți nevoie să aflați mai multe, vă recomand cu tărie să întrebați doar dezvoltatorii dvs. - nu există nimeni care să știe mai multe despre platforma dvs. CMS decât ei. Citiți mai multe despre de ce să învățați de la dezvoltatorii dvs. este cel mai bun mod de a învăța tehnologie și despre cum să începeți să vorbiți limba lor aici.

Cuprins:

1. Ce este un CMS?

• Definiție CMS
• scopuri CMS
• De ce ar trebui un sistem CMS să fie important pentru managerii CRM?

2. Ce ar trebui să înveți să gestionezi conținutul într-un CMS?

• Limbajul de marcare
• Cum să redactezi
• Cum se publică
• Unde este stocat conținutul?
• Gestionarea activelor digitale
• Analiza site-ului
• Module, widget-uri, șabloane disponibile
• Principii de bază de proiectare – UX / UI

3. Caracteristicile CMS pe care ar trebui să le cunoașteți

• Ușurință de editare
• Versiune
• Restaurare (revenire)
• Arhivare
• Compatibilitate
• Integrari
• Testare A/B
• Conținut personalizat
• Managementul traducerilor
• Optimizare SEO
• Publicare pe mai multe platforme
• Accesuri
• Lucrând în colaborare
  

4. Concepte tehnice care merită înțelese

• Site-ul dvs. este static sau dinamic?
• Lansarea site-ului
• Medii
• CMS ieșit din cutie sau personalizat?
• CMS fără cap
• Ce este un API?
• Ce sunt webhook-urile?
• Ce sunt SDK-urile?
  

5. Rezumat

Ce este CMS?

Content Management System ( CMS ) – este o aplicație software care poate fi utilizată pentru a gestiona crearea și modificarea conținutului digital. Este o „bază de date” în care vă păstrați conținutul: active digitale (imagini, videoclipuri, podcasturi), text, traduceri, în unele cazuri aspectul paginii, părți ale designului (tabele, butoane etc.). Conținutul stocat în CMS poate fi difuzat pe site-ul dvs. web, aplicația mobilă sau alte canale digitale (sms, e-mail, smartwatch etc.). Nu toate companiile stochează tot conținutul în același CMS; adesea unele soluții de „stocare” de conținut sunt separate (conținutul de e-mail în platforma de trimitere a e-mailurilor, conținutul aplicației mobile stocat ca cod și actualizat doar de dezvoltatori etc.).

CMS poate servi mai multor scopuri decât publicarea conținutului pe canalele dvs. digitale. În funcție de API-urile, pluginurile, webhook-urile disponibile, poate:

• exportați și importați traducerile,
• transmite conținutul pe platformele de social media, platformele de e-mail și alte canale,
• stocați toate activele digitale într-un singur loc și clasificate,
• pregătiți testarea A/B a conținutului și personalizarea conținutului,
• configurați SEO pe pagină,
• returnează rezultate pentru motorul de căutare pe pagină,
• și altele.
  

De ce ar trebui un sistem CMS să fie important pentru managerii CRM?

CMS este (sau ar putea fi, dacă îl configurați astfel) centrul oricărei comunicări adresate clienților . Poate difuza conținut pe propriile platforme și se poate integra cu diferite stive de marketing pentru a difuza conținut în anunțurile plătite. De asemenea, puteți gestiona SEO pe pagină de acolo. Dacă acest lucru nu este suficient, puteți configura formulare de colectare a e-mailurilor, puteți încărca politici privind cookie-urile pentru a colecta date despre clienți în sistemul dvs. CRM, unde puteți segmenta clienții și puteți oferi conținut personalizat acestor segmente din același CMS. În CMS, puteți configura teste A/B pentru conținutul dvs. sau puteți configura conținut personalizat. Puteți alimenta baza de date a chatbot-ului dvs. de acolo. De asemenea, vă puteți integra sistemul CMS cu instrumente de automatizare a marketingului, unde puteți crea reguli de segment, care vă permit să transmiteți conținut către anumiți clienți din CMS prin diferite canale de distribuție (de exemplu, trimiterea unui memento de coș uitat prin e-mail celor care au cumpărături neterminate în coșul lor).

Ce ar trebui să înveți să gestionezi conținutul într-un CMS?

Limbajul de marcare:

Sistemul dvs. CMS folosește fie un editor WYSIWYG (în acest caz, este ușor să editați conținutul pentru editorii de conținut), fie un fel de limbaj de marcare (pe care dvs. sau editorul de conținut ar trebui să-l învățați).

Ce este un limbaj de marcare?

Un limbaj de marcare este un limbaj care adnotează text, astfel încât computerul să poată manipula acel text (faceți-l bold, italic, centrați-l, colorați-l etc.). Practic este o limbă prin care poți comunica computerului cum vrei să afișeze textul sau materialele pe care le editezi.

HTML este un exemplu de limbaj de marcare:

<p>

Acesta este un paragraf de text scris în HTML

</p>

Această propoziție este alcătuită dintr-o etichetă de deschidere (<p>), text și o etichetă de închidere (</p>). Textul dintre etichete va fi afișat pe ecran. Fiecare etichetă include un simbol „mai puțin decât” și „mai mare decât” pentru a o desemna ca parte a markupului.

Cum să înveți un limbaj de marcare? Dacă acesta este un limbaj de marcare specific CMS, ar trebui să îl puteți găsi în manualul CMS. Dacă este un limbaj de marcare standard, există multe resurse online disponibile pentru a le învăța, cum ar fi, de exemplu: MOOC, Udemy, EDX, Codecademy sau Coursera.

Dacă CMS-ul dvs. nu are un editor WYSIWYG, ar putea fi de asemenea benefic să cunoașteți câteva elemente de bază ale CSS (Cascading Style Sheets) care funcționează cu HTML pentru a adăuga stiluri paginilor web pe care le editați.

Cum se redactează:

Ce ar trebui să verificați în manual sau să întrebați dezvoltatorii dvs.:

Cum să creezi o schiță a conținutului (și să nu-l publici din greșeală)? Cum să testați schița, puteți vedea o previzualizare a modului în care ar arăta pe site direct în CMS? Dacă o previzualizare directă în CMS nu este disponibilă, există vreun mediu de testare în care ați putea verifica conținutul nou redactat?

Cum se publică:

Ce ar trebui să verificați în manual sau să întrebați dezvoltatorii dvs.:

Cum se publică conținutul pe site-ul live? Puteți face acest lucru singur (sau editorul de conținut însuși) din CMS? Aveți nevoie de o versiune a site-ului web pentru actualizarea conținutului? Trebuie să ceri dezvoltatorilor ajutor pentru publicare? Este o soluție mixtă, ceea ce înseamnă că o parte a conținutului poate fi publicată din CMS de către editorii de conținut, dar unele modificări ar avea nevoie de sprijin pentru dezvoltatori? Care dintre ele au nevoie de sprijin pentru dezvoltatori? Care sunt termenele medii dacă doriți să publicați ceva, cât timp ar dura? Pe cine să contactați dacă conținutul se întrerupe și dvs. sau editorul de conținut nu îl puteți remedia singuri? Pe cine să contactați în afara orelor de lucru dacă aveți nevoie de asistență urgentă? Puteți programa publicarea conținutului în viitor? Puteți programa mai mult de un „pachet” de conținut în viitor? Dacă programați o bucată de conținut în viitor, puteți încă modifica și publica alte părți ale conținutului sau pachetul programat va îngheța orice altă publicare din momentul în care îl creați și până la ora programată? Vă puteți aminti conținutul programat dacă, dintr-un motiv oarecare, vă răzgândiți?

Unde este stocat conținutul?

Este o întrebare importantă pe care ar trebui să o adresați dezvoltatorilor/arhitectului.

Ce conținut vine de unde? Ce conținut este stocat în CMS, care în motoarele/sisteme de plată sau rezervare, care este stocat direct în FE? Ar trebui să știți ce conținut este posibil de editat în CMS, care are nevoie de dezvoltare (sau unde să găsiți astfel de informații atunci când aveți nevoie). Ar trebui să existe documentație disponibilă despre aceasta sau editorii dvs. de conținut ar trebui să o cunoască.

Gestionarea activelor digitale:

Ar trebui să știți ce tipuri de active digitale sunt acceptate de CMS-ul dvs. Puteți folosi videoclipuri, imagini, fișiere mp3? Ce extensii de fișiere pot fi utilizate? Care sunt cerințele pentru active? Verificați specificațiile pentru dimensiunile și greutatea imaginii. Sistemul va redimensiona automat imaginile sau ar trebui să le redimensionați întotdeauna înainte de încărcare? Dacă nu doriți să faceți site-ul dvs. web sau altă platformă încet, ar trebui să urmăriți întotdeauna să aveți greutatea minimă necesară pentru a afișa corect activul.

Module disponibile, widget-uri, șabloane disponibile:

Ar trebui să aflați cu ce lucrați. Aveți „blocuri de bază” pe care să le utilizați de la început (sau deja prefabricate de dezvoltatorii dvs.)? Trebuie să solicitați întotdeauna crearea personalizată a modulelor de conținut, a șabloanelor de pagină? Care este flexibilitatea șabloanelor out-of-the-box, cât de mult le puteți schimba dacă doriți să arate diferit? Modulele sunt integrate cu niște afișaje FE (front-end), deci nu aveți nevoie de nicio construcție suplimentară de site pentru a le face să apară pe site? Având cel puțin o bibliotecă de bază de module și șabloane disponibile, poate scurta foarte mult timpul de lansare pe piață al creării de noi pagini, de la câteva săptămâni de dezvoltare la câteva ore de alegere și joc cu posibilitățile de personalizare.

Principii de bază de proiectare – UX / UI:

Cunoștințele de bază despre design, în special experiența utilizatorului și interfața cu utilizatorul (UX/UI) pot fi foarte utile. Când lucrați cu designeri (de exemplu pentru a crea un nou formular de abonare, un nou microsite) veți ști cum să vorbiți cu ei, ce să cereți și cum să le evaluați munca.

Analiza site-ului:

Pentru a vă înțelege clienții, comportamentul, preferințele acestora, pentru a evalua performanța paginilor de destinație sau a formularelor de abonare nou lansate, va trebui să învățați cum să utilizați software-ul de analiză a site-urilor web pe care compania dumneavoastră îl folosește (sau să configurați unul singur). Este util să aflați ce este urmărit în mod implicit pe site-ul web (unde sunt plasate etichetele) și ce fel de urmărire ar trebui să solicitați în mod specific, de exemplu urmărirea evenimentelor personalizate sau canalele personalizate.

Caracteristicile CMS despre care ar trebui să aflați

Ce ar trebui să știți despre sistemul dvs. CMS? La ce ar trebui să cauți atunci când alegi un sistem CMS? Despre ce ar trebui să-i întrebați dezvoltatorii pentru a înțelege ce este posibil și ce nu?

Ușurință de editare:

Cât de ușor este CMS de utilizat din perspectiva unui editor de conținut? Acest lucru va influența timpul de lansare pe piață al conținutului. Ceea ce poate influența viteza de editare sunt: ​​funcțiile de glisare și plasare, „blocuri” flexibile cu care să construiți pagini, fluxuri de lucru automate (de exemplu pentru trimiterea/primirea traducerilor), conținutul populat dintr-o singură sursă (de exemplu: module dinamice, unde actualizați). conținut o dată și va apărea pe diferite subpagini și chiar pe diferite suprafețe digitale), sincronizarea conținutului între medii (elimină necesitatea de a copia și lipi tot conținutul în medii diferite).

Versiune:

Dacă CMS-ul dvs. permite salvarea versiunilor anterioare de conținut, dacă creați o nouă versiune a conținutului, dar vă răzgândiți dintr-un motiv oarecare, puteți restaura versiunea anterioară. Uneori, este chiar posibil să vedeți comparația dintre versiuni și să aveți evidențiate automat părțile care au fost schimbate.

Restaurare (revenire):

Dacă conținutul dvs. se întrerupe după o lansare, ar trebui să puteți reveni la versiunea anterioară de conținut pentru a o remedia temporar, până când dezvoltatorii dvs. pot investiga de ce conținutul a eșuat în primul rând.

Arhivare:

CMS-ul ar trebui să vă permită să arhivați conținutul. Ceea ce este important de știut este cât timp sunt stocate arhivele/versiunile de conținut vechi. Ar trebui să luați în considerare cu atenție cerințele legale pentru diferite tipuri de conținut și, eventual, să prelungiți durata de viață a conținutului arhivat pentru conținutul cu risc ridicat (de exemplu: termeni și condiții, conținut de promovare, politică de confidențialitate, consimțământ pentru cookie-uri) care ar putea fi necesar în viitor pentru anchete juridice.

Compatibilitate:

O cerință de bază pentru un sistem CMS este compatibilitatea cu arhitectura dvs., back-end, front-end, sistemele de plată, sistemele de rezervare, orice software extern pe care îl utilizați în acest moment.

Integrari:

Un sistem care oferă integrări cu alte software-uri pe care compania dumneavoastră le folosește deja sau care poate integra cu ușurință alte părți ale stivei dvs. de marketing, fie nativ, fie prin conectivitate API, vă va economisi timp și bani pe care altfel ar trebui să-i cheltuiți pe integrări personalizate.

Testare A/B:

Ce ar trebui să verificați în manual sau să întrebați dezvoltatorii dvs.:

Aveți vreo posibilitate de a crea teste A/B de conținut (mai multe versiuni de conținut care ar fi plasate în același substituent și ar putea fi comutate cu software-ul de testare A/B)? Dacă nu, îl pot dezvolta dezvoltatorii pentru tipurile de conținut (module, blocuri) pe care trebuie să le testați? Cât timp ar dura?

Conținut personalizat:

Aveți instrumente de personalizare (software)? Ce tip de conținut poate fi personalizat în acest moment (ce tip de conținut pot fi create mai multe versiuni în CMS care ar fi comutate de sistemul de personalizare)?

Dacă sistemul dvs. CMS se poate integra cu instrumentul de personalizare, puteți continua să utilizați un singur sistem pentru stocarea conținutului, ceea ce facilitează reutilizarea conținutului și gestionarea acestuia (faceți modificări în cazul modificărilor denumirii unui produs, modificări ale traducerii). sau când doriți să implementați orice alte modificări pe mai multe platforme). ‍

Managementul traducerilor:

Dacă doriți să difuzați versiuni localizate ale site-ului, sistemul dvs. CMS ar trebui să aibă suport lingvistic . Funcționalitatea minimă înseamnă posibilitatea de a stoca versiuni în diferite limbi ale aceluiași conținut în același CMS. Ceea ce recomand, pe baza experienței cu site-uri web multilingve (20+ limbi) și alte platforme digitale, este ca CMS-ul să aibă toate limbile stocate în același loc pentru același modul/bloc de conținut. Care este diferența? Dacă păstrați versiuni de limbi diferite în același CMS ca o „copie” a aceleiași structuri de site, pentru a găsi același modul și a-l actualiza în toate limbile, va trebui să deschideți fiecare versiune de limbă, să găsiți unde se află acest modul în fiecare și apoi actualizați-l. Dacă aveți versiunile de limbă direct la nivelul modulului, este ușor să găsiți același conținut și să îl actualizați în toate limbile, fără să vă pierdeți căutându-l în CMS.

Gestionarea versiunilor de conținut în diferite limbi este o muncă grea. Este consumatoare de timp și are o rată mare de eroare (dacă dvs./editorul de conținut copiați ceva greșit). Cel mai simplu mod de a gestiona traducerile este să ai o integrare cu software-ul agenției de traduceri din CMS. În acest fel, ar trebui să puteți trimite conținut original pentru traducere (de exemplu, din engleză) în diferite limbi direct din CMS și să primiți traduceri de la agenția de traduceri. Vă economisește timp (fără copiere-lipire), reduce riscul de eroare și îmbunătățește timpul de lansare pe piață. În unele cazuri, este chiar posibilă activarea afișării linkurilor de previzualizare către agenția de traduceri, ceea ce face și mai ușor pentru traducători să traducă conținutul. Traducerile proxy sunt și mai ușor de gestionat. Ceea ce face traducerea proxy este să vă populați site-ul web în versiuni proxy, localizate. Agenția de traduceri creează apoi aceste versiuni lingvistice și le servește. Reduce foarte mult timpul de editare a conținutului, dar funcționează numai pentru site-uri web, nu și pentru alte platforme precum aplicații mobile, e-mail, SMS. Pentru a acoperi alte platforme, ai avea nevoie de un alt tip de integrare, de exemplu API.

Ceea ce poate fi, de asemenea, o caracteristică utilă sunt notificările automate odată ce traducerea sosește de la agenția de traduceri sau dacă există probleme găsite la exportul/importul traducerilor (care ar putea fi configurate cu webhook-uri, dacă CMS-ul nu o furnizează în afara... cutia).

Sfat: o expresie pe care o veți auzi în continuare de la dezvoltatori – localurile – sunt ca limbile, dar cu granulație mai fină. În timp ce germana este o singură limbă, există multe locații germane diferite: de-DE pentru germană în Germania, de-AT pentru germană în Austria, de-CH pentru germană în Elveția etc.

Optimizare SEO:

Puteți gestiona SEO pe pagină din CMS-ul dvs.? Puteți personaliza singur adresele URL? Aveți câmpuri pentru metatitlu, metadate, metaetichete? Puteți adăuga etichete <h1>? CMS creează automat harta site-ului și îi adaugă pagini noi odată ce sunt publicate sau trebuie să le ceri dezvoltatorilor să facă asta pentru tine? Cum puteți configura hreflang-uri și etichete canonice dacă populați conținut în mai multe locuri sau publicați în mai multe limbi? Ar trebui să știți care sunt posibilitățile și când trebuie să vă contactați dezvoltatorii.

Publicare pe mai multe platforme:

Sistemul dvs. CMS poate servi conținutul altor platforme digitale (aplicație mobilă, e-mail, ceas inteligent, chatbot etc.)? Îl poți configura să facă asta? Este o întrebare importantă, dacă intenționați să mențineți mai multe canale de comunicare digitală. Păstrarea întregului conținut într-un singur loc are avantaje mari, cum ar fi reducerea complexității gestionării conținutului, reutilizarea conținutului, reutilizarea traducerilor, reducerea riscului de a avea conținut inconsecvent pe diferite platforme.

Acces:

Sistemele CMS pot oferi diferite tipuri de acces cu drepturi diferite. Poate fi util dacă doriți să aveți mai multe persoane care redactează, revizuiesc, aprobă conținutul sau dacă unii editori ar trebui să poată accesa doar anumite tipuri de conținut (de exemplu, un anumit departament are acces doar la conținutul care aparține departamentului respectiv) .

Lucrul în colaborare:

Dacă aveți mai mulți editori care editează conținutul, ar fi util să aveți o opțiune de a lucra în colaborare la o singură bucată de conținut. Unele sisteme CMS blochează fișierul dacă un utilizator îl are deschis, altele vă permit să editați simultan.

Concepte tehnice care merită înțelese:

În funcție de cât de strâns trebuie să lucrați cu dezvoltatorii CMS, managementul CMS sau editarea conținutului, este posibil să doriți să vă aprofundați puțin mai mult în subiecte mai tehnice. Iată câteva subiecte care merită înțelese:

Site-ul dvs. este static sau dinamic?

Site dinamic înseamnă că clienții descarcă conținutul direct de pe serverele dvs. În acest caz, puteți modifica conținutul ad-hoc, iar modificările vor fi trimise automat pe site-ul live pentru toți clienții care vă reîncarcă site-ul.

Site- ul web static înseamnă că conținutul (și codul) este împachetat și lansat cu o lansare a site-ului web, din când în când (frecvența variază în funcție de companie/tip de cod). Clienții pot ajunge doar la acea versiune statică, creând mult mai puțină sarcină pe serverele dvs. Modificarea conținutului de pe site-ul web static este posibilă numai cu lansarea site-ului web. Dacă aveți un astfel de site web, ar trebui să aflați când sunt lansările, când conținutul trebuie să fie pregătit pentru ele. Uneori, site-urile web statice au câteva soluții pentru a publica conținut între versiuni, ar trebui să înțelegeți constrângerile acestor soluții (ce poate fi publicat în acest fel, cât durează accesarea cu crawlere - împachetarea conținutului într-un pachet - și publicare).

Lansare site :

Lansarea site-ului web înseamnă livrarea unui nou cod (și conținut) pe site. Dacă trebuie să lucrați în jurul lansărilor de site-uri web sau dacă un anumit conținut poate fi livrat doar cu o lansare a site-ului web (deoarece sunt stocate în aplicații FE, de exemplu), ar trebui să aflați care este cadența echipei dvs. de dezvoltare - cât de des o preia. noi evoluții? Cât de des sunt lansările? Când trebuie să-i informezi cu privire la noua inițiativă de a o avea live pe site, care este time-to-market de la solicitare până la livrare (time-to-delivery)?

Medii:

Mediile sunt entități dintr-un spațiu care vă permit să creați și să mențineți mai multe versiuni ale datelor specifice spațiului și să le faceți modificări izolate. Având diverse medii, permiteți dezvoltări paralele, testare și integrare continuă, ceea ce vă ajută echipa să livreze mai mult de 1 proiect simultan și să lucreze într-un mod agil (dezvoltare și testare în același timp).

CMS ieșit din cutie sau personalizat?

Soluțiile ieșite din cutie pot lipsi de flexibilitate și ar putea fi dificil să le personalizezi. Soluțiile personalizate necesită multă întreținere și fiecare upgrade vă va costa mult efort, ceea ce înseamnă costuri imprevizibile de dezvoltare (în comparație cu costurile fixe ale licenței). Cea mai bună soluție este ceva intermediar: o soluție ieșită din cutie, care oferă suficientă flexibilitate, astfel încât să nu fie nevoie să faceți multe personalizări. Acesta este un alt motiv pentru care sistemele CMS bazate pe API sunt, pentru majoritatea companiilor, cea mai bună soluție disponibilă în acest moment.

CMS fără cap:

CMS „Standard” (nu headless) oferă un back-end cu o interfață simplă pentru a crea conținut, o bază de date pentru a stoca active digitale și o posibilitate de a publica conținutul. Conținutul este extras de front-end și publicat pe o pagină. Front-end-ul și conținutul sunt cuplate, nu puteți actualiza conținutul fără aplicația front-end. Totul este lansat într-o singură găleată – conținut, imagini, HTML, CSS. Acest lucru poate însemna că conținutul trebuie să apară în aceleași versiuni ca și codul front-end (prin urmare, poate fi actualizat mai rar), poate limita, de asemenea, utilizarea CMS doar la site-uri web (deoarece conținutul și codul sunt amestecate, conținutul nu poate să fie publicate în mod flexibil pe diferite canale digitale).

O abordare diferită a difuzării conținutului este un CMS „fără cap” – dacă stratul de prezentare al unui site web este „capul” unui CMS, atunci tăierea acelui strat de prezentare creează un CMS fără cap. În acest caz, depozitul de conținut „corp” este separat de stratul de prezentare. Acest lucru permite unificarea întregului conținut într-un singur hub de conținut fără cap, de unde același conținut poate fi publicat pe mai multe canale. Acest lucru face editarea mult mai ușoară - schimbați copia sau imaginea într-un singur loc, iar această modificare va fi aplicată oriunde se află conținutul. CMS-urile fără cap împart sarcinile back-end și cele front-end – aceasta înseamnă că dezvoltatorii pot codifica și proiecta rapid experiențe front-end în limba lor preferată (fără a fi legați de tehnologii back-end restrictive). În schimb, ei pot folosi interfețe de programare a aplicațiilor (API) pentru a conecta funcțiile back-end, cum ar fi stocarea și gestionarea conținutului, la orice mediu de livrare front-end. Face dezvoltarea de noi pagini sau ecrane de aplicații mobile mult mai rapidă și mai ușoară.

Citiți mai multe despre platformele de comerț electronic fără cap aici.

Ce este un API?

Sistemele API-first (API – Application Programmable Interface) au cod care permite o comunicare clar definită între două aplicații separate. Sunt platforme software moderne, care oferă managerilor CRM câteva blocuri gata făcute de funcționalități pe care le puteți pune împreună pentru a se potrivi nevoilor dumneavoastră în aproape 100%. Sunt pregătiți pentru integrare rapidă cu alte sisteme.

„API: Poștașul

Gândiți-vă la un API ca la un poștal care livrează cererea aplicației dvs. către un alt software și apoi aduce răspunsul înapoi la aplicația dvs. Un exemplu simplu: este API-ul care permite comunicarea între Google Calendar și aplicația dvs. de călătorie, astfel încât atunci când un utilizator rezervă o călătorie, aceasta se sincronizează cu calendarul său.” Sursa: Clevertap

Citiți mai multe despre ce sunt API-urile și ce ar trebui să știți atunci când alegeți software-ul API-first aici.

Ce sunt webhook-urile?

Webhook-urile sunt similare cu API-urile, dar mai simple. Un API este un limbaj complet pentru o aplicație cu funcții sau apeluri pentru a adăuga, edita și prelua date. Cu un API, trebuie să faci singur treaba. Dacă construiți o aplicație care este conectată la alta cu ajutorul unui API, aplicația dvs. va trebui să aibă modalități speciale de a cere celeilalte aplicații date noi atunci când are nevoie de ele. Webhook-urile, pe de altă parte, sunt proiectate pentru o anumită parte a unei aplicații și sunt automatizate. Este o conexiune simplă, unu-la-unu, care rulează automat.

Un exemplu de webhook ar putea fi o notificare către e-mailul dvs., declanșată atunci când o nouă traducere ajunge în CMS-ul dvs.

Ce sunt SDK-urile?

SDK înseamnă kit de dezvoltare software – un set de instrumente software și programe utilizate de dezvoltatori pentru a crea aplicații pentru platforme specifice. Instrumentele SDK includ biblioteci, documentație, mostre de cod, ghiduri și procese pe care dezvoltatorii le pot folosi și integra în propriile aplicații, concepute pentru platforme sau limbaje de programare specifice.

SDK – oficiul poștal/magazinul de hardware:

Dacă API-ul este un mailman, atunci ce este SDK-ul în acest context?
Este oficiul poștal ȘI magazinul de hardware combinate. Deoarece poate conține tot ceea ce este necesar pentru a comunica cu un alt software (adică unul sau mai multe API-uri), precum și materiale care pot fi folosite pentru a construi o aplicație complet nouă (adică biblioteci de coduri, facilități de depanare, note tehnice, tutoriale și documentație). (...) este un kit de dezvoltare. SDK-ul poate conține unul sau mai multe API-uri plus utilități esențiale. API-ul este doar o parte a unui SDK. Gândiți-vă la devkit ca la un „container” mai mare pentru o gamă întreagă de instrumente SDK și veți avea dreptate.” Sursa: Clevertap

Rezumat:

În calitate de manager CRM, ar trebui să cunoașteți câteva elemente de bază despre platformele CMS. În cele mai multe cazuri, mai devreme sau mai târziu, va trebui să publicați ceva conținut. Elementele de bază absolute de care aveți nevoie sunt să cunoașteți fluxurile de lucru și procesele de la compania dvs. dacă aveți editori de conținut care să o facă pentru dvs. Dacă trebuie să editați și să publicați singur conținut, poate doriți să aflați câteva elemente de bază ale platformei utilizate, cum ar fi cum să editați, să redactați, să publicați conținutul și care sunt posibilitățile de testare sau programare a modificărilor de conținut. Dacă aveți nevoie de cunoștințe mai avansate, ar trebui să aflați puțin mai multe despre opțiunile de testare A/B, personalizare și optimizare SEO în platforma dvs. actuală. Este recomandat să știi puțin despre cum funcționează echipa ta de dezvoltare și cu cât timp în avans trebuie să planifici dezvoltările, dacă o simplă editare de conținut nu este suficientă. Ar trebui să vă familiarizați mai bine cu procesele lor, mai ales dacă aveți nevoie să eliberați conținut cu lansările site-ului web (de exemplu, dacă site-ul dvs. este static sau CMS-ul dvs. nu este fără cap). A face cunoștință cu limbajul dezvoltatorului vă va ajuta să începeți conversația. După ce învățați elementele de bază și citiți manualul, vă recomand cu tărie să începeți doar să puneți întrebări dezvoltatorilor pentru a vă aprofunda înțelegerea - acestea sunt cea mai mare sursă de informații despre stiva dvs. existentă!