Технологічний стек

Інструменти й технології — інфраструктура, на якій тримається значна частина спільноти. Ці системи впливатимуть на кожен аспект того, як ваше видання підходить до спільноти, — від публікації матеріалів до обробки карткових платежів. Кожне видання має ухвалити десятки технологічних рішень: будувати новий продукт чи використати зовнішнього постачальника? якого постачальника обрати? скільки платити за продукт чи послугу? Ці рішення — не лише про технології. Ваш технологічний стек відображає ваші цінності й підтримує редакційну місію. Технологічні рішення можуть допомогти створити чудову орієнтовану на спільноту журналістику й підтримати повноцінну спільноту. Варто думати про ціннісну пропозицію спільноти й досвід, який хочете створити, приймаючи технологічні рішення.

Але технологічні рішення можуть мати й непередбачені наслідки та обмежувати опції в майбутньому. Цей розділ дає інформацію, контекст і застережні історії для правильного вибору, а також кейси й поради на випадок, якщо ви успадкували невдалий технологічний вибір чи обмежені бюджетом. Якщо у вас немає власної технічної експертизи — CTO, провідного інженера чи розробників, — варто розглянути найм консультанта чи технічного лідера.

Щоб зібрати перелічені тут інструменти, дослідницька команда опитала редакції по всьому світу про те, якими інструментами й сервісами вони користуються для виробництва контенту й обслуговування учасників. Цей розділ не включає кожну отриману пропозицію, але намагається представити розмаїття варіантів у категоріях: система керування контентом (CMS), провайдер email-розсилок (ESP), CRM, керування соцмережами, платіжні платформи, аналітика аудиторії, реєстрація/пейвол, платформи «все в одному», інструменти коментарів і слухання.

Нижче — ключові функції, на які варто звертати увагу в кожній категорії, і орієнтовна інформація про ціни (де доступна публічно). Якщо ви некомерційна організація, багато з цих інструментів і сервісів пропонують спеціальні знижки.

CRM і API: основи

Будуючи технологічний стек для спільноти, варто спершу зрозуміти два ключові поняття: системи керування взаємодією з клієнтами (CRM) та програмні інтерфейси застосунків (API). CRM відстежує ваших читачів і учасників. API дозволяє різним програмним системам (наприклад, вашій CRM) «спілкуватися» одна з одною.

Що таке CRM? Успішні спільноти вміють відстежувати всі способи, якими людина взаємодіє з брендом, — від читання матеріалу чи наводки до фінансового внеску. Щоб запустити, розвивати й підтримувати спільноту, потрібно розуміти, як людина з вами взаємодіє і що спонукає її вас підтримувати. Стежити за діями аудиторії — і учасників, і не-учасників — допомагає CRM.

Найважливіше, що варто знати про CRM і спільноту: не існує CRM, спроєктованої спеціально для керування спільнотою в медіа (проблема, яка дуже цікавить MPP). За відсутності спеціалізованого рішення видавцям доводиться користуватися наявними CRM-інструментами чи платформами «все в одному» з вбудованою CRM-функціональністю.

Що таке API? Критичний технічний інгредієнт для побудови спільноти поверх універсальної CRM — розумне використання API. API — це інтерфейси, що дозволяють даним «витікати» з однієї програмної системи для використання чи аналізу в іншій. Сила API в тому, що можна одночасно брати дані з кількох систем і поєднувати їх для повнішої картини того, що відбувається у вашому технологічному стеку.

Наприклад, через API вашої CRM і провайдера розсилок можна отримати email-адреси учасників і передплатників розсилки — і порахувати, наскільки ці дві групи перетинаються. За допомогою розробника чи постачальника можна автоматично об'єднувати дані з різних систем, рахувати важливі метрики й створювати дашборди, що подають міжфункціональні дані для ухвалення рішень.

Щоб використовувати дані таким чином, переконайтеся, що інструменти, які ви ліцензуєте, мають відкритий API, — це дозволяє зовнішнім розробникам (чи вам самим) отримувати доступ до даних програмно, а не через ручне завантаження.

Система керування контентом

Журналістика — серце будь-якої моделі спільноти в медіа. Ваша CMS — інструмент, що дозволяє публікувати матеріали на сайті. Критично важливо мати CMS, яка легко публікує різні типи контенту й підтримує інші ключові інструменти — CRM, ESP.

Приклади: WordPress/NewsPack, Squarespace, Drupal, Chorus, Arc, Brightspot, Ghost, The News Project, Opennemas.

Обов'язкові функції: створення й керування сторінками та окремими одиницями контенту; керування шапкою/футером/навігацією; заходи безпеки для кількох користувачів (двофакторна автентифікація, ролі адміністраторів).

Бажані функції: централізована медіатека (керування цифровими активами); прості плагіни/інтеграції для розширення можливостей; відкриті API для зв'язку з іншими системами.

На що звернути увагу: підтримка CMS — окрема гра, зосереджена на чотирьох напрямах — патчі безпеки й оновлення; безвідмовність, продуктивність, бекапи; додавання нових функцій; оновлення вигляду й користувацького досвіду. Чи платитимете розробнику за кожну зміну? Якщо купуєте готовий продукт, чи допоможе постачальник кастомізувати рішення під ваші потреби зі зростанням? Безпеку й технічну підтримку зазвичай покриває повністю хостоване рішення на кшталт NewsPack чи WordPress VIP, але оновлення вигляду майже завжди лишається на вас.

Провайдер email-розсилок

Email — критичний інгредієнт успішної спільноти. Розсилки допомагають перетворити випадкових читачів на постійних відвідувачів і учасників, а список email — ефективний спосіб звернутися до спільноти під час кампаній набору й прохань про підтримку.

Приклади: MailChimp, Constant Contact, Engaging Networks, Substack, Revue, Sailthru, Pardot, ConvertKit.

Обов'язкові функції: керування списками й сегментами контактів (краще — з синхронізацією з CRM); створення й дизайн шаблонів розсилки; масові розсилки (розсилки й кампанії набору); автоматично тригерні листи — вітальні чи серії онбордингу («drip-кампанії»); реєстрація нових користувачів у списках на сайті; можливість відписки й керування налаштуваннями.

Бажані функції: автоматизовані листи про поновлення й прострочення картки; банери чи спливні заклики до дії на сайті; інтеграція через API з CMS і CRM; інтерактивний контент у листах (наприклад, GIF); умовне форматування для розділів «лише для учасників».

На що звернути увагу: вартість (більшість ESP визначають ціну за розміром списку чи об'ємом розсилки — з ростом спільноти витрати теж зростуть); тривалість контракту (деякі тарифи «прив'язують» на 2+ роки); зручність (наскільки простий конструктор шаблонів); функції на основі ШІ («інтуїтивні» — часто зайві та не завжди працюють); аналітика даних (деякі платформи мають потужну аналітику, інші — майже жодної).

CRM: що шукати

Скільки учасників у вашого медіа? Який відсоток учасників передплачує розсилку? Які кроки читач зробив, перш ніж стати учасником? На всі ці питання має відповідати ваша CRM. Успішній спільноті потрібна централізована база даних для розуміння й відстеження аудиторії — і учасників, і не-учасників.

Приклади: Sugar CRM, Salesforce, Hubspot, Google Таблиці, Airtable, Pico, ReachNC Voices, Nimble.

Ваша CRM має відстежувати всіх учасників і контактів — email-адреси, статус участі, платежі й поновлення, налаштування підписки та іншу інформацію про взаємодію з вашим сайтом. Це має бути єдине джерело правди про всі контакти.

Обов'язкові функції: масове імпортування контактів (наприклад, .csv-файлів); зручний пошук/сортування/сегментація; спосіб розрізняти учасників і не-учасників; відстеження взаємодій (дзвінки, листи, зустрічі) з потенційними й наявними учасниками чи донорами; заходи безпеки (двофакторна автентифікація).

Бажані функції: просунуте тегування й сегментація; поле внутрішніх нотаток для персоналу.

На що звернути увагу: чи зберігаються дані в одній плоскій таблиці (як у електронній таблиці), чи в динамічнішій структурі (база даних, кілька зв'язаних таблиць)? Чи легко система «спілкується» з вашою CMS та ESP (через API, стороннню інтеграцію чи плагін)?

Платіжні системи

Читач спожив вашу журналістику, взаємодіяв зі спільнотою й вирішив приєднатися. Наступний крок — надати платіжну інформацію, найімовірніше — дані картки. Системи оплати дозволяють приймати платежі від читачів — важливо, щоб процес був простим для майбутнього учасника.

Приклади: Stripe, PayPal, Square, Braintree, Reveniu, PayU, Mercado Pago (для України — Fondy, LiqPay, WayForPay та подібні локальні процесори).

Обов'язкові функції: відповідність стандарту PCI, що гарантує безпеку карткових транзакцій; найвищі стандарти безпеки (токенізація, наскрізне шифрування); обробка (і повернення) карткових платежів; зрозуміла аналітика й звітність; керування регулярними щомісячними й щорічними платежами; автоматичне оновлення даних картки користувачем (без цього персонал витрачає багато часу, а відтік зростає без потреби).

Бажані функції: можливість подарувати участь; автоматичне поновлення (можливість вмикати/вимикати на рівні користувача); сповіщення про невдалий платіж у реальному часі; інтеграція з CRM/базою учасників.

На що звернути увагу: тарифи й комісії за різні типи платежів; мобільний і десктопний досвід; відповідність законам про приватність (зокрема GDPR); можливість приймати платежі у вашій країні й, можливо, кількох валютах залежно від того, де живе ваша аудиторія.

Аналітика аудиторії

Орієнтованим на спільноту редакціям потрібно розуміти, як аудиторія взаємодіє з висвітленням, щоб краще їй служити. На базовому рівні важливо знати розмір аудиторії й джерело трафіку. Але глибший погляд на цифрову аналітику допомагає краще обслуговувати наявних учасників і розвивати спільноту.

Приклади: Google Analytics, Chartbeat, Parsely, Omniture, Audience Explorer, Metrics for News, Memberkit.

Обов'язкові функції: щоденний запис ефективності публікацій, джерел трафіку й того, як саме користувачі потрапляють на сайт; історичний огляд ефективності контенту з часом.

Бажані функції: застосунок чи зручний мобільний перегляд; дані в реальному часі, особливо для трафіку із соцмереж.

На що звернути увагу: чи маєте систему логіну користувачів (це дозволяє точніше відстежувати їх); чи спроєктована система саме для журналістики/медіа; наскільки складна доступна аналітика і яку підтримку в її інтерпретації надає постачальник; будь-які зобов'язання вашої організації щодо того, як ви відстежуєте (чи не відстежуєте) поведінку аудиторії. Детальніше про використання аналітики для стратегії спільноти — у розділі «Метрики спільноти».

Керування соцмережами

Соцмережі навряд чи стануть головним каналом взаємодії з найлояльнішою аудиторією (email і текстові повідомлення ефективніші), але часто саме там аудиторія вперше про вас дізнається. Щоденне керування акаунтами соцмереж може бути виснажливим — ці інструменти допомагають координувати й автоматизувати базові завдання, звільняючи час для змістовнішої роботи зі спільнотою.

Приклади: SocialFlow, Buffer, Hootsuite, Sprout Social, Postcron.

Обов'язкові функції: планування публікацій наперед; застосунок чи зручний мобільний інтерфейс; інтеграція з основними платформами соцмереж; безпека (двофакторна автентифікація); експортована аналітика (щоб поєднувати з іншими даними стека).

Бажані функції: аналітика в реальному часі; функція «слухання» (списки користувачів для стеження/сегментації); інтеграція з основним інструментом аналітики.

На що звернути увагу: скільком людям потрібен доступ до інструменту — багато з них тарифікують за кількістю користувачів.

Реєстрація і пейвол

Багато медіа роблять частину висвітлення доступною лише учасникам. Якщо це частина вашої ціннісної пропозиції спільноти, знадобиться інструмент, що обмежує доступ і забезпечує реєстрацію. Навіть якщо контент повністю безкоштовний, система реєстрації може бути цінною для збору email-адрес і побудови глибших, звичніших стосунків з аудиторією.

Приклади: Piano, Pico, Pigeon Paywall, Ghost, Steady.

Обов'язкові функції: інтеграція з CMS для керування доступом до контенту; проста, зручна реєстрація й логін; вбудований процес оформлення й інтеграції з платіжними системами, що не заважають досвіду читача; інтеграція з CRM/базою учасників і аналітикою аудиторії.

Бажані функції: A/B-тестування й динамічний лічильник переглядів; підтримка кількох способів оплати (PayPal, Apple Pay, Google Pay); логін через соцмережі.

На що звернути увагу: обмеження доступу до контенту звужує аудиторію й потенційно обмежує верх вашої лійки — варто зважити, чи цей підхід правильний для вашого бізнесу; чи підтримує обрана система реєстрації вашу стратегію пейволу.

Інструменти для спільноти

Залученість спільноти — серце всієї моделі. На відміну від передплати, спільнота — не транзакційні стосунки, а відчуття приналежності й причетності до організації, орієнтованої на місію. Інструменти побудови спільноти дозволяють залучати учасників — і потенційних учасників — у процес репортажу і враховувати їхній голос у висвітленні, а також проводити дослідження аудиторії.

Обираючи інструменти для онлайн-спільноти, підходьте через призму «роботи, яку потрібно виконати»: обирайте інструмент за тим, що сподіваєтеся дізнатися від спільноти. Ось кілька таких завдань:

Зібрати думку спільноти — розгляньте Hearken. Софт і консалтингові послуги Hearken допомагають медіа залучати аудиторію на кожному етапі роботи над матеріалом — від задуму до публікації, даючи змогу пропонувати теми, голосувати за них і змістовно брати участь. Наприклад, KPCC-LAist використав Hearken, щоб збирати й відповідати на питання спільноти про коронавірус — станом на серпень 2020 року станція відповіла на понад 4000 питань.

Спілкуватися з читачами напряму, один на один — розгляньте GroundSource, Subtext, Reach від EdNC, WhatsApp чи інші месенджери. Текстові повідомлення (SMS чи месенджер на кшталт WhatsApp) дають редакції прямий зв'язок з людиною на пристрої, де вона проводить найбільше часу, — і можуть ефективно охоплювати тих, у кого немає доступу до інтернету. За даними дослідницької фірми M+R, «аудиторія некомерційних текстових розсилок зросла на 26% 2019 року — тоді як аудиторія Facebook зросла лише на 4%, а списки email скоротилися на 2%».

GroundSource — платформа й консалтинг для двостороннього текстового спілкування; Chalkbeat Tennessee використав її, щоб повідомляти батьків у Мемфісі про безкоштовне харчування під час локдауну, бо в багатьох сімей не було доступу до інтернету, але SMS доходило. Subtext (від Advance Media) підтримує SMS-розмови з аналітикою й монетизацією — BuzzFeed News використав її, щоб збирати питання читачів про коронавірус і перетворювати їх на рубрику. Reach від EdNC — частина ширшої платформи для залученості через розсилки, текстинг, опитування; EdNC щотижня опитує аудиторію про освітні новини Північної Кароліни через Reach. WhatsApp — багато видавців використовують месенджер Facebook для новин та оновлень; некомерційна редакція Documented, що висвітлює імміграційну спільноту Нью-Йорка, вела популярну WhatsApp-розсилку й оновлювала аудиторію про COVID-19 через неї.

Провести обговорення в спільноті — розгляньте Coral від Vox Media, Discourse чи Crowdstack. Coral — платформа коментарів з відкритим кодом «Talk», що підтримує поважні, орієнтовані на спільноту дискусії з інструментами для модераторів. Аргентинська Página/12 використовує Coral Talk як перевагу лише для учасників — можливість коментувати статті й спілкуватися з журналістами стала стимулом приєднуватися до спільноти. Discourse — платформа обговорень з відкритим кодом, що працює і як список розсилки, і як форум, і як довгий чат; Метт Кайзер з WTF Just Happened Today хостить спільноту на Discourse, бо вона безкоштовна й відкрита. Crowdstack хостить спільноти на сайті з інструментами сегментації за ролями, дозволами й відстеженням активності.

Платформи «все в одному»

Малим і однолюдним редакціям потрібні інструменти з великим важелем — які роблять багато за мінімум зусиль, керування чи технічної експертизи. Платформи «все в одному» можуть бути єдиним інструментом чи конектором між різними системами, що поєднує кілька функцій підтримки спільноти. Це також хороший поштовх для редакцій, які лише починають і хочуть запуститися з мінімально життєздатним продуктом, зосередившись на журналістиці й побудові спільноти.

Приклади: Patreon, Memberful, News Revenue Hub, Steady, Pico, Substack, NewsPack, BlueLena.

Такі платформи поєднують різні технічні компоненти спільноти в єдиний стек. Інтегровані сервіси на кшталт News Revenue Hub і Memberful комбінують і кастомізують набір інструментів доходу — ESP, CRM, платіжний процесор та інше. Інші, як Pico й Steady, підключаються до наявного сайту для обробки платежів, обмеження доступу до контенту й керування учасниками. Такі платформи, як Patreon і Substack, підтримують і публікацію контенту, і керування платежами, розсилками, CRM.

Обов'язкові функції: безшовний зв'язок між платформою публікації, ESP і платіжною системою; інструменти керування учасниками; аналітика; контроль над брендингом, щоб платформа не заглушала ваш власний бренд.

Бажані функції: рівні участі з різними ціновими точками; інтеграція з аналітикою; зв'язок із соцмережами й зовнішніми платформами; самообслуговування облікового запису для учасників.

На що звернути увагу: обравши таку платформу, можна опинитися «прив'язаними» до її системи — перехід до іншого постачальника, найімовірніше, зупинить автоматичні регулярні платежі учасників, і доведеться просити їх приєднатися знову, ризикуючи втратити багатьох. Постачальник платформи може зберігати контроль над даними користувачів чи платіжною інформацією, що ускладнює перехід. Якщо мета — зростання, варто мати план міграції даних учасників і історичних метрик, коли настане час масштабуватися до нового набору інструментів. Зважайте й на комісії платформи та рівень підтримки, який вам потрібен — деякі сервіси, як News Revenue Hub, поєднують технічний функціонал з консалтингом і навіть аутсорс-маркетингом.

Купити чи побудувати

Рішення «купити чи побудувати» — одне з найважливіших технологічних рішень для медіа. Використання будь-яких інструментів зрештою служить вашим учасникам і спільноті, тож потрібно переконатися, що обрані платформи справді задовольняють ці потреби.

У виборі купити чи побудувати є компроміси. Жодна готова технологія не задовольнить усі потреби, але те, що ви втрачаєте в гнучкості, купуючи готове рішення, ви заощаджуєте в часі й коштах порівняно з побудовою власного інструменту.

Коли варто купити (ліцензувати) інструмент: якщо вам бракує кадрової спроможності (без навичок і ресурсу підтримувати систему з часом MPP не радить будувати власну — підтримка кастомних інструментів часто джерело стресу для технічних команд редакцій); якщо бракує бюджету (розробка на замовлення коштує дорого й вимагає і початкових інвестицій, і постійної підтримки — якщо немає бюджету на дослідження й розробку, не будуйте; якщо є початковий бюджет через грант, але немає впевненості в бюджеті на підтримку — теж не будуйте); якщо знайшли достатньо хорошу альтернативу (для малих і середніх редакцій готове рішення, що задовольняє більшість потреб чи легко кастомізується, — краще, ніж будувати з нуля).

Якщо плануєте купувати чи ліцензувати, майте на увазі: більшість ПЗ належить до однієї чи кількох категорій — відкритий код (створений і підтримуваний спільнотою розробників, зазвичай безкоштовний для впровадження базового коду — приклад: CMS WordPress; майте на увазі десятки типів ліцензій відкритого коду з різними умовами); безкоштовний інструмент (створений для безкоштовного використання, можливо з платним рівнем — безкоштовна версія може обмежувати функціональність чи брендування, наприклад Canva); частина набору інструментів (деякі компанії пропонують «готовий» набір взаємопов'язаних інструментів — наприклад, Salesforce, відомий CRM-платформою, пропонує й ESP, і маркетингову автоматизацію).

Коли варто побудувати власний інструмент: побудова власного технологічного рішення — вагоме рішення, що дає більший контроль над функціональністю й кастомізацією. Причини будувати самим: ніщо наявне не відповідає особливим потребам вашої редакції (після дослідження всіх опцій ви впевнені, що ринкові продукти не задовольняють ваші потреби — власний продукт дає більше контролю над функціями й безпекою); ви прагнете масштабуватися (зростаюча організація може швидко переростати функціональність готового інструменту); ви шукаєте нову бізнес-модель (побудова власних інструментів створює можливість нового потоку доходу — згодом можна ліцензувати технологію іншим організаціям, якщо ваші потреби відображають потреби багатьох інших у галузі).

Особливий випадок — оновлення інфраструктури. У некомерційній медіаекосистемі є великий рух на підтримку технологічного розвитку малих і середніх редакцій, особливо для оновлення CMS, CRM та ESP. Дослідницька команда MPP бачила багато малих редакцій, що переживали сплеск зростання, а потім упиралися в технічні системи (особливо CMS і CRM), які більше не відповідали потребам. Хоча оновлення інфраструктури — значна технологічна інвестиція (навіть за зовнішнього фінансування), оновлення базових систем зазвичай служить довше й краще сприяє довгостроковій стійкості організації, ніж побудова й запуск окремих інструментів.

Ми не радимо малим і середнім редакціям будувати власну базову інфраструктуру (особливо CRM і CMS). Але якщо можна знайти фінансування для оновлення до наявної, перевіреної системи, яка зробить публікацію й фандрейзинг точнішими й ефективнішими, — така інвестиція варта того, за умови правильного бюджетування витрат на міграцію, підтримку персоналу й обслуговування з часом.

Коли спільнота El Diario зростала, іспанська редакція зрозуміла: потрібні кращі інструменти для обслуговування учасників і редакції. За підтримки гранту Google DNI вони вирішили інвестувати в побудову власної CRM.

Тим часом The Dispatch у Вашингтоні співпрацював із Substack, щоб адаптувати систему під свої потреби. Малий стартап відмовився від частини функцій, але зберіг час і кошти персоналу, які інакше пішли б на розробку.

Приватність і дані

Спільнота будується на довірі. Один зі способів, яким учасники демонструють цю довіру, — ділячись особистою інформацією. Незалежно від того, дають вони номер картки, фізичну адресу чи email, потрібно бути впевненими, що ця інформація в безпеці, і бути прозорими щодо того, як ви її використовуєте.

Обираючи інструменти й сервіси для спільноти, зверніть увагу на три кроки. Подумайте, скільки даних аудиторії вам справді потрібно. Більше даних — не завжди краще. Забагато даних, особливо чутливих, — ризик, особливо якщо зберігати їх неналежно. Вивчіть політики приватності постачальників. Що вони роблять із даними ваших користувачів? Чи є пункти, що дозволяють продавати дані третім сторонам? Створіть власну політику приватності й опублікуйте її на сайті. Дайте їй окрему сторінку, посилайтеся на неї і з розсилок.

Політики приватності email і керування підписками. Явна політика приватності особливо важлива для того, як ви використовуєте email-адреси читачів. Читачі мають самі підписуватися на розсилки й маркетинг, і відписка має бути простою й очевидною.

Свідомо ставтеся до трекінг-пікселів. Багато видавців розміщують на сайтах піксели, що зв'язують поведінку користувача з Facebook, Google чи іншими компаніями. З огляду на дедалі більшу настороженість аудиторії щодо практик роботи з даними великих платформ, варто усвідомлювати, скільки інформації ви їм передаєте. Інструменти на кшталт Ghostery чи Privacy Badger допоможуть перевірити трекери на сайті.

Свідомо ставтеся до програматичних рекламних мереж. Хоча вони можуть здаватися способом отримати додатковий дохід, вони можуть стати кошмаром приватності й вектором для шкідливого ПЗ.

Зробіть свої цінності приватності явними. Це теж спосіб побудувати довіру з аудиторією. Наприклад, американське The Markup обмежує збір даних і чітко пояснює це на сайті: «Ми обіцяємо нашим читачам: The Markup збиратиме про вас якнайменше особистих даних під час відвідування сайту, і ми ніколи не монетизуватимемо ці дані». Вони обрали ESP Revue саме тому, що можна повністю вимкнути відстеження користувачів.

The Correspondent визначив як один зі своїх основних принципів мінімізацію збору даних, каталогізуючи лише те, що вимагає закон і що потрібно для базової роботи сайту:

«Більшість безкоштовних онлайн-сервісів дозволяють користувачам «платити», віддаючи особисті дані. У The Correspondent ми мінімізуємо дані, які збираємо про вас. Ми збираємо лише те, що вимагає закон або що потрібно для коректної роботи платформи (наприклад, логін і пароль). Ми не продаємо цю інформацію третім сторонам. Причини збору даних мають бути пояснені чітко. І там, де можливо, учасники мають контролювати зібрані дані».

Дотримуйтеся місцевих, національних і міжнародних законів про приватність. Ваша технічна конфігурація завжди має відповідати місцевим законам про приватність. Каліфорнія та Європа мають особливо суворі вимоги, що ставлять контроль користувача над своїми даними на перше місце. Навіть якщо ви не базуєтеся в регіоні з суворими законами про приватність, але маєте користувачів там, — вам потрібно відповідати цим регуляціям.

Кілька орієнтирів для дотримання ключових регуляцій: GDPR (регулює приватність в ЄС), CAN-SPAM Act 2003 у США (регулює маркетингову email-комунікацію), California Consumer Privacy Act (дає споживачам більший контроль над своїми даними).

Зобов'язання мінімізувати збір даних не мусить обмежувати здатність ухвалювати рішення на основі даних. De Correspondent показує, як використовує якісні інсайти замість відстеження учасників на сайті.

Якщо ви успадкували безлад

Дехто з вас може стикатися з успадкованими технічними проблемами. Ці «безлади» можуть ускладнити роботу зі спільнотою. Приклади: попереднє керівництво підписало довгостроковий контракт із системою, яка погано працює; ви прив'язані до корпоративного контракту з іншими спорідненими організаціями; хтось припустився помилки в попередньому впровадженні — «крапки» більше не з'єднані, і дані не можуть «спілкуватися» між частинами стека; ключовий співробітник пішов, не залишивши «ключів» до інструменту чи коду; ви застрягли на застарілій CMS, що не дозволяє додавати заклики приєднатися до спільноти.

Можливо, ви навіть не підозрюєте про безлад. Ось прості перевірки: підпишіться на власну розсилку — чи прийшов правильний лист, чи додали вас у правильні списки? станьте учасником — чи позначили вас правильно в CRM? в ESP? протестуйте все важливе — форми реєстрації, сторінки оформлення участі — на різних пристроях і в різних браузерах.

Можливо, рішення, ухвалене раніше, мало наслідки, коли потреби організації змінилися: аудиторія виросла, і потрібен новий ESP для більших списків; організація виходить на новий ринок і потребує підтримки додаткових валют; постачальник закрився, і потрібен перехід на новий сервіс.

Особливо важливо для малих редакцій, що зростають, документувати й окремо зберігати власні ключові показники ефективності. 2019 року філадельфійський новинний сайт Billy Penn придбала громадська медіаорганізація WHYY, і в результаті злиття довелося інтегрувати дві окремі системи спільноти. Залишаючи попереднього власника, Billy Penn налаштував нові екземпляри свого основного стеку — конектор Salesforce-Mailchimp-Stripe від News Revenue Hub. Дані вдалося перенести, але історична інформація про учасників — наприклад, історія взаємодії з розсилками Billy Penn — була втрачена. «Спочатку це фрустрація, — сказала редакторка Billy Penn Данья Хеннінгер, — без цієї інформації складніше точково звертатися до читачів із запрошенням до спільноти».

Хеннінгер шкодує, що не завантажувала регулярно ключові дані окремо від платформ, щоб не втратити їх при переході. «Хоч би який у вас технологічний стек — ведіть власні записи, — каже вона. — Визначте свої KPI й відстежуйте їх самі, навіть якщо не звітуєте про них назовні».

Оновлення технічних систем може створювати новий безлад, який доведеться прибирати пізніше, — зважте витрати й вигоди, особливо коли оновлення включає перенесення великих обсягів контенту й даних. Ризик втрати даних при міграції має бути виправданий потужнішим функціоналом. Закладайте достатньо часу й ресурсів на оновлення.

Хоча команда Billy Penn цінує гнучкість свого стеку News Revenue Hub, вони з нетерпінням чекають майбутньої інтеграції з системою WHYY, щоб отримати доступ до її величезної бази email — у Billy Penn близько 25 000 передплатників розсилки, у WHYY — понад 250 000 контактів.

Метту Кайзеру з WTF Just Happened Today двічі доводилося переносити дані — трудомісткий процес, який зрештою виявився вартим цього обидва рази.

Найм розробників і консультантів

Багато редакцій не мають штатної технічної команди. Орієнтуючись серед різних інструментів і можливого успадкованого безладу, ви можете вирішити, що потрібна зовнішня допомога.

Інвестиція у фрилансера чи постачальника може бути виправданою, якщо це спростить процеси або дозволить зосередитися на головному — якісній журналістиці й обслуговуванні учасників. Розробники в медіагалузі зазвичай належать до трьох категорій: фронтенд (сторона, що бачить користувач), бекенд («під капотом») і фулстек (обидва напрями). Що саме вам потрібно від такої людини?

Типові завдання для розробника: написати код для стороннього API, щоб з'єднати дві системи; кастомізувати готовий інструмент під потреби організації; переробити шаблони розсилки під мобільний досвід; оптимізувати вітальну серію та інші автоматизовані листи; налаштувати аналітику й звіти; обрати й впровадити продукти постачальників, наприклад CRM.

Чого уникати: тих, хто не пояснює речі чітко й з повагою — вам потрібен той, хто зустріне вас на вашому рівні технічної обізнаності й допоможе ухвалювати обґрунтовані рішення; розробників без досвіду роботи з медіа — ідеальний постачальник дасть професійне рекомендаційне контактне лице в журналістській галузі; тих, хто ніколи не працював з медіаорганізацією — не обов'язково працювати саме в редакції, але досвід із галуззю потрібен.

Ключові нагадування для роботи з підрядниками: зберігайте право власності на документацію — кодову базу, цифрові активи, навчальні матеріали, паролі й чітке пояснення, як підтримувати код і отримувати підтримку; чітко визначте, хто має «ключі» до стека — хто має доступ до сторінок логіну (враховуючи і штатних, і підрядників), хто має адмін-доступ (завжди щонайменше двоє, бажано з різних відділів), хто може відновлювати й створювати паролі (як часто оновлюєте головні паролі? чи використовуєте менеджер паролів для всієї організації?), хто може створювати й видаляти нових користувачів/адмінів (створіть чекліст для приходу й відходу співробітників, включно з видаленням доступу після звільнення).

Оцінка постачальників

Будь-який зовнішній сервіс, яким користується ваша організація — внутрішньо чи назовні, — асоціюється з вашим брендом і надсилає сигнал учасникам. Так само, як у вас є стандарти для журналістики й пропозицій спільноти, варто переконатися, що постачальники узгоджуються з вашими цілями й місією.

Вибір постачальника — не лише про пошук правильних інструментів, а й про те, чи стане компанія хорошим технологічним партнером для вашої організації. Ось ключові напрями оцінки.

Конкурентне дослідження: погугліть «назва постачальника + конкуренти» — можливо, хтось уже порівняв інструменти, які ви розглядаєте; поговоріть з колегами з інших редакцій про те, чим вони користуються і які плюси й мінуси; попросіть рекомендації — більшість постачальників радо направлять до попередніх клієнтів у медіасфері; якщо ні — це тривожний сигнал.

Клієнтський сервіс: угода про рівень обслуговування (SLA) — ключова частина контракту, що визначає, як швидко постачальник відповідає на запити підтримки; запитайте про різні типи запитів підтримки — від дрібниць (заблокований акаунт у будній день) до повного збою у вихідні; чи буде виділений контакт підтримки (наприклад, телефон) чи доведеться звертатися через портал (наприклад, Zendesk).

Демонстрація й перевірка концепції: завжди просіть повну демонстрацію функцій і записуйте демо, щоб повернутися до нього пізніше; хороший постачальник дасть безкоштовний пробний період чи тестове середовище; наполягайте — перед демо складіть список усього, що потрібно від інструменту, і попросіть продемонструвати кожен пункт; якщо не хочуть демонструвати якусь функцію — варто запитати чому.

Прогноз витрат: недостатньо знати вартість покупки й впровадження — потрібен повний аналіз витрат на весь термін контракту, включно з кастомізацією, оновленнями, постійною підтримкою й обслуговуванням; попросіть повністю пояснити всі рівні тарифів і чи залежить ціна від розміру аудиторії (і що станеться, якщо аудиторія раптово різко зросте).

Дорожня карта продукту: попросіть показати продуктову дорожню карту — якщо плануєте бути клієнтом рік і більше, варто знати, які функції можуть додати; які функції близькі до релізу; які функції найчастіше просять інші медіаклієнти; як часто випускають масштабні оновлення; що станеться з вашими даними, якщо з компанією щось трапиться протягом терміну контракту.

Безпека: чи можуть (чи мусять) усі користувачі увімкнути двофакторну автентифікацію; чи інструмент збирає й зберігає персональні дані (PII) і чи можна обмежити доступ до них; чи практики роботи з PII відповідають регуляціям приватності, релевантним для вашого розташування й аудиторії (GDPR тощо); чи використовує інструмент шифрування для передачі ключових даних; як постачальник реагує на патчі безпеки й зломи — як часто, коли був останній серйозний випадок.

Варто також розглянути залучення зовнішньої допомоги для консультації з вибору й впровадження постачальника. У багатьох ситуаціях вам може бракувати досвіду для обґрунтованого вибору — три постачальники можуть обіцяти ідентичні функції, сервіс чи безпеку, а дати геть різний результат. Оскільки помилки в розробці складно й дорого виправляти, консультант, що допоможе перевірити постачальників і пропозиції, може бути вартим початкової інвестиції.