2021 | Бізнес Майстерня

2021

91,8% всіх пошукових запитів Google є низькочастотними

Кросворд

А середня ціна за клік за ключовим словом становить 0,61$. Причому пошукові запити, пов'язані з фінансами і нерухомістю, мають найвищу середню ціну за клік.

Спеціаліст по SEO Брайан Дін, Backlinko, проаналізував 306 мільйонів ключових слів на основі даних DataForSEO і Ahrefs, щоб скласти портрет запитів, які люди вводять в пошуку Google.

Ключові висновки

1. 91,8% всіх пошукових запитів є низькочастотними (long tail keywords). У цьому дослідженні будь-яке ключове слово з 1-100 запитами в місяць розглядалося як «довге» ключове слово.

ключові

Але навіть в сукупності вони складають лише невелику частину глобального пошукового попиту - всього 3,3% від загального обсягу пошуку.

пошук

2. Велика частина пошукових запитів крутиться навколо високочастотних ключових слів. Фактично, 500 найпопулярніших пошукових запитів складають 8,4% всього обсягу пошуку. А на 2000 найпопулярніших ключових слів доводиться 12,2% всіх пошукових запитів в Google.

3. У середньому ключове слово отримує 989 запитів в місяць. Однак середній обсяг пошуку за ключовим словом становить всього 10 пошуків в місяць.

4. 14,1% запитів формулюються у формі питання. Найбільш поширений початок запиту - питальне слово «як» (how), за ним слідують «що» (what), «де» (where) і «хто» (who).

питання

6. Середня ціна за клік по ключовим словом становить 0,61$. Причому пошукові запити, пов'язані з фінансами і нерухомістю, мають найвищу середню ціну за клік.

ціна за клік

7. Середній запит складається з 1,9 слів в середньому довжиною 8,5 символів. Є взаємозв'язок між довжиною запиту і обсягом пошуку. Якщо подивитися на кількість символів, дуже довгі і короткі ключові слова викликають відносно мало пошукових запитів. Найчастіше шукають ключові слова з 5-10 символів.

довжина

Причому у ключових з 1-2 слів найвищий середній обсяг пошуку.

запити

8. Довші ключові слова шукають рідше, ніж більш короткі. Фактично, ключові слова, що містять більше 5 слів, отримують в середньому в 10 разів менше запитів, ніж пошукові запити довжиною в 1-3 слова.

9. Галузі з найбільшим обсягом пошуку - це «Новини і ЗМІ», «Інтернет і телекомунікації», «Мистецтво і розваги» і «Побутова електроніка».

сегменти

10. Люди в основному шукають інформацію, галереї картинок або відео. Найпопулярніша категорія в результатах Google - «Люди також запитують» (19,4%), далі йдуть картинки (19,4%), відео (17,9%), головні новини (15,4%) і додаткові посилання (11 , 0%).

Найпопулярніші категорії

Читати дослідження запитів Google повністю.

Фото: flickr.com
Обробка: Vinci
Читати далі

Як керівнику контролювати інтернет-маркетологів

воронка

За якими показниками стежити і як витрачати на це мінімум часу.

Отже, у вас є сайт і інтернет-маркетолог (або ціле маркетингове агентство на підряді).

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

У ваших стосунках все не так райдужно? Пропонуємо спосіб це виправити.

Відразу обмовимося: мова піде не про e-commerce (це особливий світ зі своїми законами), а про ті сфери, де через сайт можна тільки замовити товар або послугу - саме вони зазвичай страждають від недостатньої аналітики.

Вимірювати і управляти

Ще в минулому столітті засновник американської школи менеджменту Пітер Друкер сказав: «Управляти можна тільки тим, що можна виміряти». Сподіваємося, сьогодні вам уже не потрібно нагадувати, що оцінювати маркетинг необхідно за цифрами, а не за суб'єктивним відчуттям «працює/не працює».

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

Як це зазвичай влаштовано в середньому бізнесі:

  • Маркетинг не рахується взагалі. Просто є сайт, який приносить «мало» або «дуже мало» клієнтів. Часто саме з такими вихідними даними вперше звертаються до агентства.
  • Щось обліковується час від часу, десь в екселі. За цим звичайно треба радикальний крок - зміна маркетолога або вкладання грошей в новий рекламний канал. А потім все триває, як і раніше.
  • Звіт робиться регулярно, але містить якісь загальні цифри, які створюють видимість активності. Як з цим працювати - незрозуміло, тому раз по раз цифри майже не змінюються, якщо не змінюється рекламний бюджет.

Як це повинно бути влаштовано:

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

Ви зможете оцінювати роботу маркетологів і приймати правильні рішення, якщо ваш звіт дає швидку відповідь на важливі питання:

питання

Що рахуємо

Звичайно, нам в першу чергу важливо, скільки грошей ми вклали в маркетинг і скільки клієнтів отримали. Але цього мало.

Невеликий лікнеп з інших важливих показників в порядку зростання значущості для бізнесу:

  • CPC (cost per click) - ціна за клік. Корисна тільки фахівцю, який веде рекламу.
  • CPL (cost per lead) - ціна за лід, тобто звернення потенційного клієнта (дзвінок і зворотний дзвінок, заявка через форму або пошту, звернення в чат).
  • CPS (cost per sale) - ціна продажу.

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

Це може бути ціна продажу, але тут є кілька нюансів:

  • Для аналізу продажів потрібна CRM система, а її інтеграція - це окремий непростий процес.
  • Якщо товар дорогий, з довгим циклом продажу, то даних для аналізу буде занадто мало.
  • Сам факт продажу сильно залежить від менеджера, який спілкується з потенційним клієнтом, тому оцінювати таким чином саме маркетинг буде некоректно.

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

Як це організувати технічно

  1. Підключаємо коллтрекінг - сервіс відстеження дзвінків з сайту. Коштує він не так дорого, але якщо ви даєте рекламу або просуваєте сайт в пошуку, без нього не обійтися.
  2. Налаштовуємо цілі в Google Analytics - відстежуємо всі види цільових дій, що здійснюються нашими потенційними клієнтами.
  3. Далі це все в кращому випадку збирається в Ексель, але для управління такий варіант не годиться. Потрібна професійна система аналітики - зрозуміла, автоматизована і, на жаль, зазвичай платна.
таблиця

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

Навіщо? Будь-яка проблема повинна бути очевидна і відразу кидатися в очі. У 1986 році космічний корабель «Челленджер» розвалився в повітрі. Інженери НАСА попереджали керівництво про проблему і пропонували перенести старт. Але керівники не надали проблемі великого значення через складно оформлений звіт.

звіт
Це хороший звіт - в ньому проблема відразу очевидна

Дізнайтеся, яка рекламна кампанія витрачає ваші гроші даремно. Не дайте своєму Челленджеру вибухнути!

Навчилися рахувати - що далі

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

Для поетапної оптимізації допоможе проста воронка:

Кому продаємо

Аналізуємо вартість ліда в кожному з рекламних каналів, підбираємо аудиторії, працюємо з настройками показів

Як продаємо

Працюємо з пошуковими запитами і оголошеннями

Що продаємо

Підвищуємо конверсію сайту - його інформативність і зручність

Гарна аналітика дозволить швидко зрозуміти, на якому саме етапі ви втрачаєте гроші, сформулювати завдання і відстежити ефект від змін.

ефект

Після вказівки цін на сайті (послуги преміум-сегмента) ціна ліда різко зросла. Ціни вирішили прибрати.

Після періоду «просто поліпшення» і спостереження за показниками можна переходити до постановки довгострокових цілей (на 3-6-12 місяців).

Як ми це робимо:

  • Звіт показує нам, де ми зараз - кількість і вартість лідів по рекламних каналах, конверсія, кількість продажів.
  • Формулюємо бажаний обсяг продажів і «розкладаємо» по каналах потрібну кількість лідів.
  • Дивимося, за рахунок яких етапів воронки можна досягти зростання.
  • Пов'язуємо це з реальністю: наприклад, підняти конверсію вище 5% або розраховувати отримати з SEO більше трафіку і лідів, ніж основні конкуренти старші за нас - дещо самовпевнено.

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

розрахунки

Короткий підсумок

  1. Якщо ви вкладаєте в рекламу або просування сайту без якісної аналітики - ви втрачаєте гроші.
  2. Вартість ліда (звернення) - це той показник, на який варто дивитися в першу чергу для оцінки маркетингової активності.
  3. Щоб керувати своїми вкладеннями і говорити з маркетологами на одній мові, вам потрібен простий і інформативний звіт, який завжди під рукою.
  4. Якщо ваш маркетолог або підрядник не може надати такий звіт - знайдіть іншого. Ваше завдання - приймати рішення, а не намагатися розібратися в звітах.
  5. На першому етапі впровадження системи контролю потребуватиме додаткових витрат, але дуже швидко окупиться і почне приносити прибуток. Ви зможете керуватися чіткими критеріями ефективності маркетингу, і вам більше не доведеться розбиратися в нюансах з кожним новим підрядником. Краще витратити цей час на інші важливі цілі - пошук шляхів зростання і розвитку вашого бізнесу.
Фото: flickr.com
Обробка: Vinci
Читати далі

Чим же займаються програмісти, і як пояснити це іншим

код

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

Як розповісти їм про це, не лякаючи страшними термінами і фрагментами коду?

Для цього ми відтворимо таку розповідь, а також розвінчаємо кілька міфів про програмування.

- Чим займаються програмісти? Це не так-то просто розповісти... Скажіть мені для початку: як в двох словах можна описати, наприклад, суть професії хірурга?
- Хірург проводить операції.
- Так, відмінний опис! Ну а, скажімо, футболіста?
- Грає у футбол!
- Угу, а хірург «займається хірургією». А якщо без однокореневих слів?
- Штовхає м'яч?
- Ось це точно. А що ж робить програміст, крім як «розробляє програми»?
- ...
- Програміст пише код. Вихідний код своєї програми, складений на якійсь спеціальній мові програмування. Точніше кажучи, спочатку він продумує структури своїх даних, потім складає алгоритми для роботи з цими структурами - ну а потім вже представляє це в вигляді коду.
- Що ще за «структури даних»? Хіба він не керує комп'ютером, не натискаючи кнопки?
- Ех...

Міф №1: Програміст працює з комп'ютерами

Спробуйте донести до людей, що програмісту для написання коду, взагалі-то, зовсім не потрібен комп'ютер. Він потрібен лише для перевірки коректності коду, для його тестування - але писати сам код і складати схеми алгоритмів цілком можна і на папері (хоча на екрані монітора, звичайно, це робити зручніше). Розробник же просто записує на цьому папері набір якихось інструкцій, команд або конкретних даних (числа, текст). А хто цей набір виконує - комп'ютер, телефон або особливо розумний робот, не так вже й важливо. Програміст працює з даними, а не з машинами.

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

цифри

Міф №2: Машина вміє думати

Чомусь чимале число людей реально вважає, ніби комп'ютер володіє якимось інтелектом. Насправді - це просто набір залізяк, які думати не вміють. Вони вміють лише зберігати числові дані. Розмагнічено якусь ділянку такої залізяки - значить, це нуль. Намагнічений - одиниця. Плюс, ще вони можуть додавати і віднімати ці одиниці, утворюючи більш складні числа (про двійкову систему числення краще не варто згадувати). Більше комп'ютер сам нічого робити не вміє, тільки зберігати числа і оперувати ними. Це бездумний дурень, який лише виконує команди програміста.

- Загалом, код будь-якої програми представляє собою набір команд, а комп'ютер їх тупо виконує.
- Тобто, він не розуміє суті самих команд? Але як він сприймає текст, який я ввожу на екрані?
- Коли ти крутиш педалі на велосипеді - чи розуміє він, що йому зараз потрібно поїхати вперед?
- Ні, але ж їде. Оскільки його ланцюг перетворює обертання педалей в обертання колеса.
- Саме так! Так само і комп'ютер перетворює введений тобою текст в набір чисел.
- Яким чином?
- У кожного символу тексту є свій числовий код, який знає комп'ютер. Це називається кодуванням. Наприклад, англійська «a» кодується числом 97, а знак рівності - числом 61.
- Тому машина і може розуміти текст, який ми їй повідомляємо?
- Ні, вона «розуміє» не сенс. А лише те, яким чином цей текст зберігати, і як до нього звертатися.
- Виходить, спочатку ми вводимо текст, потім комп'ютер розбиває його на символи, а кожен символ вже представляє у вигляді числа?
- Вірно. Складні структури представляються у вигляді більш простих, які і «розуміє» машина.

Скажіть мені, з чого складається житловий будинок?
- Ну... З поверхів.
- А з чого складаються поверхи? І так далі.
- Поверхи - зі стін. А стіни - з цегли. А цеглу...
- Ось числа для комп'ютера - це те ж, що і цегла для будинку. Символи - це стіни. Окремі пропозиції - поверхи. А книги - цілі будинки! Але у програмістів є перевага перед будівельниками.
- Яке?
- Будівельник не може будувати цілими поверхами, він змушений завжди класти цеглу. Навіть якщо якийсь надпотужний підйомний кран дозволить йому будувати готові поверхи, він не зможе будувати їм цілі будинки або житлові квартали. А програміст зможе! Раз він вже «навчив» машину розуміти кінцевий текст - то, по суті, він «навчив» підйомний кран будувати готовий будинок за одну дію.
- Тобто, програміст може використовувати все більш і більш складні структури даних?
- Так. Тому перша зі складових його роботи - представити зрозумілі людині дані (текст, зображення, звук) у вигляді об'єднання простіших даних, вже зрозумілих комп'ютеру. Розробник практично «з нуля» становить структуру, яка повинна повністю описувати зрозумілу людині річ - причому таким чином, щоб ця структура була легко розширюваною і змінною (адже в програму часто доводиться вносити якісь нові можливості).
- Хех! Виходить, що він будує гумові будинку зі знімних панелей!
- Приблизно так. Однак, ще йому доведеться не лише описати, що ж йому потрібно побудувати - але і як все це побудувати. Тобто, придумати алгоритм. Це друга зі складових його роботи.
- Програміст придумує алгоритм на кожну дію?
- Саме так. Тому алгоритмів виходить дуже багато. Але його роботу полегшує те, що одні дії можуть містити в собі інші, вже описані ним раніше.
- І тут йому на допомогу приходить мова програмування?
- Не зовсім...

Міф №3: Мова програмування потрібна для складання алгоритмів

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

клавіатура

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

- Правда, багато нинішніх мов програмування вже містять «в собі» набір заздалегідь складених алгоритмів, які розробник може використовувати в якості готових. Тому мова все ж трохи полегшує процес складання алгоритмів.
- Тобто, якщо один програміст склав якийсь алгоритм, то його тут же можуть використовувати інші?
- Так, і це відбувається постійно. Це одна з причин, чому галузь IT так швидко розвивається. Однак нові алгоритми доводиться складати самому.
- А склади який-небудь прямо зараз!
- Легко. Класичний приклад: у вас є книга, в ній 1000 сторінок. Вам потрібно відкрити в ній, наприклад, 875-ю сторінку. Як би ви стали це робити?
- Ну, просто пробіг від першої до 875-ї, тільки і всього.
- Угу, і доведеться тобі дивитися на номер кожної сторінки. А уяви, якщо всі їхні куточки злиплися - скільки часу тоді пройде? А ось мені достатньо перебрати лише 3 сторінки!
- Як?
- Спочатку я виберу сторінку, яка знаходиться посередині книги, тобто 500-ю. Потім подивлюся: в яку з утворених половин повинна потрапити шукана сторінка?
- У другу. А далі що?
- Теж саме. Інтервал з 500-ї по 1000-ю я знову поділю надвоє, відкривши центральну сторінку. Вийде інтервал від 750-ї сторінки до 1000-й, в ньому я знову виберу центральну. Якою буде номер?
- 750 плюс 125... Так це ж і є 875!
- От бачиш. Всього 3 дії! Навіть якщо я буду не зовсім точний при виборі центральної сторінки, я все одно знайду потрібну набагато швидше тебе. Цей алгоритм носить назву «дихотомія». Хоча в реальності програмісти використовують куди більш складні алгоритми.
- І ти можеш записати його на папері?
- Звісно. Де там моя ручка?

Псевдокод
повторюємо цикл:
	
        шукаємо(в книзі, центральну_сторінку);
	
        якщо (центральная_сторінка = шуканій_сторінці)
                виходимо з циклу;
	
        інакше
                якщо (центральна_сторінка < шуканій_сторінці)
                        видаляемо(в книзі, всі сторінки від першої до центральної);
                інакше
                        видаляемо(в книзі, всі сторінки від центральної до останньої);

- Ну як, алгоритм зрозумілий?
- Хм... Так, і справді зрозумілий.
- Зараз він записаний у вигляді, вже злегка схожому на реальний програмний код.
- А в чому відмінності?
- У реальному коді всі слова будуть написані англійською, а також буде заздалегідь описана структура «книга». Плюс, для дій «шукаємо» і «видаляємо» теж будуть складені свої алгоритми. Але в цілому - все те ж саме.
- І ти займаєшся цим із дня в день?
- Переважно.
- І тобі не нудно?
- Анітрохи.

програміст

Міф №4: Програмування - це нудно

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

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

- Жартома можна сказати, що в підсумку виходить якийсь детектив в вигаданому світі, виражений за допомогою мови програмування.
- А вбивця в цьому детективі - дворецький?
- Ага, нульовий покажчик. Буває так, що весь відділ день-другий ловить особливо настирливий баг, і кожен програміст з відділу бере на себе якусь ділянку коду. Виходить ціле розслідування, з покаранням винних і нагородженням причетних...
- Хм, а це і справді цікаво звучить!
- От бачиш.
- А, скажімо, я можу хоч трохи навчитися програмуванню?
- Так звісно! Я знаю один сайт спеціально для цього...

Фото: flickr.com
Обробка: Vinci
Читати далі

Три поради від Facebook, як підвищити ефективність і охоплення відео напередодні свят

обличчя

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

Додати 3-5-секундний трейлер

Коротке прев'ю на початку відео - досить поширений підхід на YouTube, а тепер і в Facebook. Достатньо ключовий фрагмент з відео додати в початок, щоб зацікавити і захопити користувача.

Щоб побачити, в який момент перегляду ви втрачаєте глядачів, використовуйте аналітику Creator Studio.

«Відкрийте відомості про відео, натиснувши на свій ролик в бібліотеці контенту Creator Studio. Подивіться на криву утримання аудиторії і зніміть прапорець "only include views over 15 seconds", щоб зрозуміти, в якому місці люди залишають ваше відео в перші секунди перегляду. Ми рекомендуємо часто перевіряти криві утримання і прагнути покращувати час перегляду - це допоможе розширити охоплення на Facebook».

Відкадрувати відео зі співвідношенням сторін 4: 5

А краще відразу знімати вертикальні відео.

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

Внутрішнє дослідження Facebook показало, що продуктивність деяких відеороликів значно покращилася просто за рахунок перемикання з формату 16:9 на 4:5.

Facebook

Залучати свою спільноту, відповідаючи на коментарі під своїми відео-повідомленнями

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

Facebook також зазначає, що набагато простіше відповідати на коментарі до відео в Facebook і Instagram через вкладку «Вхідні» в Creator Studio:

Creator Studio

Але головне - пам'ятайте: єдина чарівна формула успішного контенту на Facebook - це ви.

Фото: flickr.com
Обробка: Vinci
Читати далі

Структура IT команди: ключові ролі, їх призначення та взаємодія на проекті

проект

Ми вирішили підготувати для Вас, друзі, невеликий екскурс в типовий IT проект. Ми часто спостерігаємо круглі очі наших майбутніх колег, коли говоримо, що в IT галузі є місце не тільки програмістам, так й і що програмістів, насправді, кілька типів. Отже, давайте розбиратися, хто ж такі "конси", аналітики, "РП", розробники, тестери.

Отже, почнемо з того, що ролі в команді можуть суттєво відрізнятися в залежності від типу проекту. Створюючи софт з нуля, Вам потрібна одна команда, впроваджуючи ERP систему - інша, ставлячи додаток BI для топ-менеджменту замовника - третя і так далі. Але тут ми вирішили розповісти Вам найбільш поширені і загальноприйняті професії і ролі, які затребувані в тій чи іншій мірі практично на будь-якому проекті.

Розробникч ДЕВ

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

Аналітики

Розглянувши роль Розробник, найлогічніше перейти до його/її самому вірного колеги і соратнику на будь-якому проекті - аналітику або бізнес-аналітику. Ці хлопці беруть на себе дуже істотну частину роботи, перебуваючи на стику бізнесу і технологій. Звичайно, як ми вже обговорили вище, ідеальною людиною був би той, хто вислухав потреби бізнесу, 100% зрозумів їх з першого разу, придумав відповідне рішення, написав по ньому документацію, розробив, протестував, навчив і порадів. Такі люди дійсно є, але набагато ефективніше в даному випадку працює зв'язка аналітик + програміст.

До типових завдань бізнес-аналітика входить:

  1. Робота з представниками бізнесу та глибоке розуміння їх процесів;
  2. Самостійна ідентифікація і аналіз проблем/вузьких місць в робочих процесах;
  3. Спіставлення знайдених проблем з потребами бізнесу, які вони самі виявили;
  4. Проектування рішення, яке задовольнить усі потреби і вирішить проблеми (найчастіше, крім проектування IT рішення, потрібно також і пропозиція з реструктуризації діяльності);
  5. Після того, як рішення спроектовано (побудовані моделі даних, описані use-case, написані специфікації на розробку), документація переходить до розробника, а аналітик продовжує постійну комунікацію з розробником для більш ефективної роботи.
гроші

Консультант Конс

У багатьох компаніях роль консультанта повністю збігається з роллю аналітика на проекті і ніякої різниці між ними немає. Однак у великих IT компаніях, ці ролі трохи розрізняються. Якщо аналітик більшою мірою фокусується на участь у проектах (і при цьому володіє більш технічними навичками, знає мови програмування на рівні читання коду для коректного написання специфікацій на розробку, розуміє в архітектурі front-end і back-end, здатний вибудувати структуру бази даних майбутнього додатка на основі вимог і потреб бізнесу, здатний розуміти, чи можна додати якусь функціональність в код і не зламати всі попередні доробки), то консультант або бізнес-консультант в більшій мірі фокусується на IT-консалтингу, тобто на тих роботах, які передують IT проекту. Консультанти проводять глибокий аналіз бізнес-процесів компанії, аналізують проблеми і пропонують варіанти проведення реінжинірингу процесів (перебудови діяльності) для більш успішного функціонування компанії, підбирають існуючі IT-рішення, які можуть допомогти бізнесу функціонувати, або проектують на верхньому рівні і пропонують замовнику розробку з нуля.

Менеджер проекту РП

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

Тестувальники тестери

Що таке тестування і хто такі тестувальники? У двох словах - це біль. Ім'я у цій ролі цілком говорить, і ці хлопці займаються тестуванням програмних продуктів. І особливість їх професії в тому, що якщо аналітика (не найбільш досвідченого) ще можна переконати, що "це не баг, а фіча", то ось цих хлопців точно ні. Фраза "на моїй машині працює" теж не врятує нікого від цих хлопців. Вони - інженери по QA (Quality Assurance) і тестують не просто зовнішню частину програми, але і коректність звернення до бек-енду, швидкодію і відмовостійкість системи, застосовуючи найрізноманітніші методики тестування.

Фото: flickr.com
Обробка: Vinci
Читати далі

Накрутити підписників в Instagram? #Ля,нашо!?

Автор матеріалу - Олексій Ткачук, творець найбільшого блогу в рунеті про Instagram Dnative.ru

Блог Dnative в соціальних мережах:

FB VK Youtube Telegram

Посилання на оригінал: Накрутить подписчиков в Instagram? #ля, зачем!?

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

накрутка

Як виглядає типовий скрипт просування чергового магазину китайського барахла або ж нової перукарні?

  1. Створити обліковий запис з назвою типу @nizki_cini_u_nas21
  2. Заповнити профіль
  3. Купити три тисячі, а ще краще п'ять тисяч підписників.
  4. Запостити перше фото з підписом «Друзі, ми починаємо».
  5. Постити фотки з корпоративів раз на тиждень.
  6. Лайкати всіх підряд.

Само собою, я трохи утрирую і перебільшую, адже хто буде публікувати фото з корпоративів раз на тиждень? Треба мінімум 5 фотографій столів з офісу і тортика Тітки Зіни з Дня Народження.

В принципі на кожному з етапів подібного просування відбуваються грубі помилки, але зупинимося на накрутках.

лебідь

Чому накручені підписники в Instagram здатні вбити ваш аккаунт?

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

І правильно роблять, ці самі «пильнуючі» алгоритми Instagram. Без вас світ стане тільки чистішим і кращим. А тепер уявіть, що ви не тільки купили ботів, але вже похвалилися керівництву про свої перші успіхи, скромно промовчавши про те, що підписники були куплені на першому-ліпшому сайті. А премію то вже пропили, та й шукати нову роботу зовсім не хочеться. Тому не треба накручувати підписників на новий акаунт! Це вбереже ваші нерви, кар'єру і премію.

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

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

фоловери

Так ось, припустимо, що ви все ж накрутили собі кілька тисяч підписників. В середньому залученість в середньостатистичному акаунті буде на рівні 1-3%. Тобто при наявності 3.000 підписників, фотографія повинна отримувати від 30 до 100 лайків. «Пффф, та це ж копійки», справедливо можете помітити ви. Адже на своїх особистих облікових записах ви збираєте набагато більше.

Тільки мова йде про комерційний акаунт. А у брендових сторінок закони життя зовсім інші, і чим більше підписників у вас буде, тим менший відсоток залучення ER ви зможете підтримувати. То ж, накрутивши тисячі підписників, лайків від цього більше не стане. І у вас залишиться тільки два виходи:

  1. Блокувати накручені акаунти вручну, але це не дуже приємне задоволення.
  2. Змиритися з низькою відносною залученістю і плакати під столом, міцно стискаючи коліна.

А другий варіант, в свою чергу, веде до ще більшої проблеми. На початку літа 2016 року, адміністрація Instagram почала масово вводити алгоритмічну стрічку новин на всі профілі користувачів. Гортали стрічку в Facebook? Ага, значить розумієте, про що йдеться.

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

шльопки

Міфи накруток. Чому люди накручують підписників

Міф 1. Велика кількість підписників залучає нових користувачів.

Багато хто чомусь вважає, що раз у вас 10.000 підписників і ви лайкаєте користувачів, то вони обов'язково побіжать на вас підписуватися, адже у вас ОГОГОСКІЛЬКИ фоловерів. Це не зовсім так, точніше зовсім не так. Принцип соціального доказу має місце бути, але в першу чергу аналізується контент, активність і відповідність акаунту цільовим інтересам користувача. А ось невідповідність кількості лайків і коментарів сумі ваших підписників цілком може зіграти фатальну роль і відлякати потенційного клієнта.

Міф 2. Багато підписників = багато клієнтів.

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

Міф 3. Всі накручують і мені треба.

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

Підпишуться і так. Інші комерційні акаунти, і це не жарт. Днями я зробив нову сторінку, яку ніяк не просував. За перші кілька днів на мене підписалося майже 80 акаунтів, серед яких були як живі люди, так і неживі бізнес-сторінки. І лайків на кожну фотографію прилітає не менш 20-30 за раз. Прям таки свято ботоводства у плоті.

Точно не накручувати?

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

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

Фото: flickr.com
Обробка: Vinci
Читати далі

21% компаній не відповідають на запити в чаті

крестики

У світі миттєвого спілкування чат стає найкращим каналом зв'язку з клієнтами, але 45% компаній не просять користувачів навіть залишити відгук після завершення спілкування.

В наші дні найбільша проблема омніканального обслуговування клієнтів - це час відгуку. Клієнти очікують негайної реакції. Superoffice провела дослідження підтримки чатів на 1000 веб-сайтах з США і Європи. Чати оцінювалися тільки в години підтримки веб-сайту, причому питання задавалися по суті. Після завершення кожного чату оцінювалася якість за часом відповіді, часом очікування і загальним досвідом спілкування.

А що в результаті?

  • На 21% запитів в чаті підтримки не відповіли.
  • Середній час очікування реакції служби підтримки в чаті складає 2 хвилини 40 секунд.
  • 55% компаній не пропонують відправити копію чату після завершення спілкування.
  • 23% компаній не запитують контактну інформацію до початку чату.
  • Середній час обробки запиту в чаті становить 6 хвилин 50 секунд.
  • 45% компаній не просять користувачів залишати відгуки після завершення чату.

Як перетворити чат в зручний і ефективний канал зв'язку з клієнтами

1. Якщо онлайн-чат є частиною вашої стратегії спілкування з клієнтами, важливо швидко реагувати на запити клієнтів. Якщо при використанні електронної пошти клієнти очікують відповіді протягом 6 годин, то в чаті - негайно. Найбільше розчарування клієнтів викликає звернення до компанії кілька разів з одного й того ж питання. На жаль, 1 з 5 чатів або 21% під час дослідження так і залишився без відповіді.

дослідження

Пропонуйте чат як варіант спілкування, тільки якщо у вас є для цього ресурси. Хоча б просто вимикайте його, якщо немає кому відповісти. Чим більше запитів в чат ви ігноруєте, тим більше клієнтів ви втрачаєте.

2. Скоротіть час відповіді за допомогою заздалегідь написаних шаблонів. Люди терпіти не можуть чекати. Середній час очікування відповіді оператора після запуску чату становить 2 хвилини 40 секунд. Всього лише кілька операторів відповіли протягом 30 секунд (що забезпечило позитивний досвід клієнтів). Максимальний час очікування склав 9 хвилин.

стовпчики

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

3. Персоналізуйте спілкування зі своїми клієнтами. Дивно, але до цього часу 23% компаній не запитують контактну інформацію до початку чату. Відсутність контактної інформації означає, що оператор чату не знає, з ким він спілкується. Попередній запит імені або адреси електронної пошти дозволить йому вибрати цінну інформацію з вашої CRM-системи заздалегідь для більш особистого обслуговування.

обслуговування

Згідно з дослідженням Economist Intelligence Unit, це призводить до скорочення часу обробки запиту і більш швидкому відгуку, що вважається найбільш важливим елементом для створення ідеального клієнтського досвіду.

4. Створюйте довгострокові позитивні враження. Після закінчення чату, замість того, щоб просто поставити галочку «виконано», відправте копію чату клієнту по електронній пошті. Наявність балки чату дозволяє клієнту продовжити спілкування в будь-який час. На жаль, більше половини (55%) чатів не пропонували таку можливість. А оператор легко може зробити копію розмови і відправити її клієнтові на email, але з 1000 компаній тільки одна виступила з такою ініціативою.

статистика

Пост-чат - також відмінний час, щоб запитати думку клієнтів про обслуговування. 45% компаній не запитували відгуки клієнтів після завершення чату. Чи був чат корисний? Чи були клієнти задоволені своїм досвідом? Якщо ви не запитаєте їх, ви ніколи не дізнаєтеся. Клієнти цінують, що їх просять дати зворотний зв'язок, але доступ до таких даних також допомагає виявляти проблемні місця, усувати і покращувати їх.

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

Фото: flickr.com
Обробка: Vinci
Читати далі

Ролі в ІТ і їх обов'язки

механізм

Текст про стереотипи і помилки, які побутують в ІТ. Про те, що розробник - це фахівець, який пише код, а тім лід - це не просто керівник групи.

Групи ролей

Ролі в ІТ можна розділити за кількома зрізами:

  • за активністю;
  • за відповідальністю;
  • за завантаженістю.

Поділ за активністю:

  • виробники;
  • управлінці;
  • перевіряючі.

Поділ за відповідальністю:

  • без відповідальності
  • з відповідальністю за якість
  • з фінансовою відповідальністю

Поділ за призначенням:

  • наймані на позицію;
  • виховувані в колективі.

Опис ролей

Назви ролей будуть використовуватись американські, звідки, по-суті, вони родом. Велика частина назв запозичена з англомовної спільноти.

Developer.

Характеристики:

  • займається виробництвом програмних алгоритмів;
  • не несе відповідальності за застосування результату і по фінансових ризиках;
  • наймається на позицію.

Ця роль класичного виконавця: керівник ставить задачу на автоматизацію того чи іншого процесу, розробник це виконує.

сходи

У сучасному світі, розробник об'єднується ще з кількома ролями, які будуть описані нижче.

Дана роль часто сегментується з розділенням відповідальності:

  • Back-end developer - розробник програмно-апаратної частини комплексного ПЗ;
  • Front-end developer - розробник клієнтської сторони призначеного для користувача інтерфейсу до програмно-апаратної частини.

Так само, роль сегментується по платформах, під які ведеться розробка, наприклад:

  • Web;
  • Mobile;
  • Server-Side;

і так далі. А для більш зручної роботи рекомендуємо користуватись ось цими розширеннями для VS-code:

User Experience Designer (UX)

Характеристики:

  • займається виробництвом карт користувацького досвіду;
  • несе відповідальності за застосування результату, але не несе відповідальність за фінансовими ризиками;
  • наймається на позицію.

Ця роль вивчає і оцінює, як користувачі відносяться до розроблюваного програмного забезпечення. Вони виявляють простоту використання ПЗ, сприйняття цінності ПЗ, корисність ПЗ, ефективність ПЗ. Продумують і оцінюють процеси і сценарії використання ПЗ.

Помилково цю роль плутають, а часом і поєднують з роллю UI Designer (див. нижче). UX vs UI Designer відрізняються не тільки предметною областю, а й специфікою мислення. UX Designer більше про аналітику і систематизацію, ніж про ергономіку і естетику.

User Interface Designer (UI)

Характеристики:

  • займається виробництвом графічної складової інтерфейсів;
  • не несе відповідальності за застосування результату і по фінансових ризиках;
  • наймається на позицію.

Ця роль розробляє візуальну частину призначеного для користувача інтерфейсу. Основними цілями роботи UI дизайнера є: интуїтивність сприйняття, простота, юзабільність і естетика інтерфейсу ПЗ.

Quality Assurance (QA)

Характеристики:

  • займається перевіркою результату;
  • не несе відповідальності за застосування результату і по фінансових ризиках;
  • наймається на позицію.

QA займається тестуванням всього, як би дивно це не звучало.

Системний підхід фахівця QA дозволяє тестувати як програмний код, так і продуманість карт користувацького досвіду.

команда

Також дуже важливий аспект роботи фахівця QA - планування, тобто вміння складати тест план, слідувати йому, готувати звіти згідно з підготовленим планом. Фахівців QA на ринку праці багато, а ось людей з системним підходом, необхідним багажем знань і умінь - одиниці.

Human Resource (HR)

Характеристики:

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

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

Обов'язки HR часто замішані з наступною роллю, яка на більшості ринків праці трактується так, як хочеться керівництву компанії.

Team Leader

Характеристики:

  • відповідає за роботу групи фахівців;
  • несе відповідальності за командну роботу, не несе фінансових ризиків;
  • вирощується в колективі.

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

Це важливо розуміти:

  1. Team Leader завжди вирощується в середовищі, це єдиний спосіб заробити авторитет в групі людей; немає авторитету, ніхто не буде слухати Team Leader, процеси йтимуть своїм шляхом;
  2. Можна процес вирощування прискорити, найнявши одного з досвідчених Team Leader, але в колектив він повинен потрапити спершу як рядовий фахівець, заробити авторитет, тільки потім перейти на цільову позицію;
  3. Роль більше не про управління командою, не про виробництво, а про рішення проблем в роботі команди, налагодження комунікації всередині команди, вибудовування комфортних умов виробництва;
  4. Team Leader зобов'язаний володіти аналітичними навичками та системним поглядом; просто робити, щоб всім було "добре" мало, основне завдання - постійне вимірювання внутрішніх метрик команди, як соціальних, так і виробничих, зміна процесів для підвищення результативності.

Чому досвідчений розробник флегматик або меланхолік не підходить на цю роль, думаю, тепер стало очевидним.

Tech Leader

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

Особливостей всіх ролей, в назві яких є слово Leader, є те, що всі вони вирощуються в колективі (див. вище).

Але дану роль ми вирішили виділити, так як, на практиці, її найчастіше плутають з роллю Team Leader.

Tech Leader так само вирощується в колективі, команді потрібен авторитет, щоб впевнено доносити свої думки і рішення з технічних питань.

Tech Leader торкається таких аспектів роботи команди:

  1. Відповідальний вибір стороннього ПЗ для проекту;
  2. Рекомендація по вибору конкретного алгоритму або архітектурного рішення при виробництві ПЗ;
  3. Визначення технічних особливостей в процесах виробництва.

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

код

Scrum Master

З появою термінів Scrum, Agile, KanBan, гнучкі методології, і інші теоретичні знання, які вкрай не приносять користі без практики/досвіду, до команд розробки стали прикріплювати роль Scram Master.

Характеристики:

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

Чому ми вирішили описати дану роль? Так склалося, що цю роль часто плутають з Project Manager.

Давайте з'ясуємо ситуацію. Scrum Master - це фахівець, який допомагає команді застосовувати методологію Scrum правильно, пояснює правила методології, контролює їх виконання.

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

Project Manager (PjM)

Характеристики:

  • відповідає за старт, ведення і здачу проектних робіт;
  • несе повну відповідальність за результат, несе часткову відповідальність за фінансовими ризиками;
  • наймається на позицію.

Ця роль класичного управлінця процесами. Робота над проектом починається з Project Manager`а, ведеться (ставляться завдання), контролюється (контроль якості та ефективності), і здається теж ним. У більшості компаній Project Manager управляє проектним фондом. Про грамотний розрахунок по digital-проекту читайте в цій статті. Коли швидкість реалізації швидше планованих термінів проекту, проектний фонд утилізується не повністю, залишається частина грошей, які за результатом успішної здачі проекту розподіляється на премії учасників. Розподілом також займається Project Manager.

Фото: flickr.com
Обробка: Vinci
Читати далі

Семантичний кокон. Теорія і практика використання

кокон

Семантичний кокон - це SEO-стратегія внутрішньої перелінковки, розроблена французьким дослідником Laurent Bourelly, спрямована на оптимізацію внутрішньої архітектури сайту шляхом семантичної класифікації контенту. При цьому сторінки сайту організовуються в ієрархічному порядку з використанням семантичної близькості сторінок і блоків контенту. Стратегія була розроблена в 2013 році у Франції, де отримала вкрай широке поширення, і є розвитком SILO-структури. За межами Франції концепція семантичного кокона слабо відома, незважаючи на те, що така структура показує значно кращі результати, ніж традиційна SILO архітектура сайту.

Концепція семантичного кокона

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

У якості відправної точки беруться до уваги запити користувачів Інтернету, які генерують найбільшу кількість цільового трафіку. При цьому необхідно передбачити майбутні запити, пов'язані з уже знайденими, під час пошуку ключових слів. Саме на цих запитах буде створена архітектура кокона.

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

Ефективність семантичного кокона повністю залежить від якості контенту та правильної перелінковки семантично близьких сторінок.

семантика
Архітектура звичайного сайту і сайту з семантичними коконами

Важливо: У будь-якого семантичного кокона є два важливих компоненти - структурна і смислова (семантична):

  • Структурний аспект - це ті посилання перелінковки, що видно на представлених вище зображеннях;
  • Семантичний (смисловий) аспект - для створення посилання необхідні вагомі підстави, наприклад семантична близькість контенту.

Без розуміння цих аспектів, цінність кокона буде прямувати до нуля. Він просто не буде працювати.

Класична структура кокона

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

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

Матріархальна організація

Зверху знаходиться цільова сторінка, зазвичай звана «мати». Контент материнської сторінки тісно пов'язаний з ВЧ ключами.

У кожної материнської сторінки є дочки - сторінки більш широко розкривають окремі аспекти материнської сторінки. Якщо обговорювати сторінки другого рівня, то між собою вони є «сестрами». Іноді, сторінки другого рівня називають «змішаними» сторінками.

У свою чергу у дочірніх сторінок другого рівня є власні дочірні сторінки (вже третього рівня). Вони також будуть сестрами для всіх сторінок третього рівня. Ще їх називають «додатковими» сторінками.

Наочно це представлено на малюнку.

схема
Матріархальна структура семантичного кокона

Зміст змішаних сторінок

Розглянемо як організована сторінка другого рівня, дочірня для материнської.

Спочатку йде H1 - заголовок сторінки, на якій ми знаходимося.

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

Чим точніше буде спозиціоноване посилання на батьківську сторінку - тим краще. Тому можна використовувати якорі на материнській сторінці і посилання на поточній сторінці можна направити точно на потрібний шматок контенту батьківської сторінки (використовуючи на посиланні #).

Далі йде H2 - заголовок, який описує тему 1-й дочірньої сторінки для поточної (сторінка нижнього, 3 рівня).

Далі йде абзац, де в кількох рядках ви пояснюєте, що відвідувач знайде на 1-й дочірній (додатковій) сторінці. Це буде опис того, про що ця сторінка в цілому. У цьому невеликому абзаці ви також розміщуєте посилання на цю першу дочірню сторінку. Якір посилання буде описувати зміст 1-ї додаткової сторінки.

Далі йде текст, необхідний для часткового розкриття змісту поточної сторінки.

Після цього ставимо ще один H2 - заголовок, який описує тему 2-й дочірньої сторінки (сторінка нижнього рівня).

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

Далі йде текст, необхідний для часткового розкриття змісту поточної сторінки.

Проставляємо знову H2 - заголовок, який описує тему 3-й дочірньої сторінки (сторінка нижнього рівня).

Як пояснювалося раніше, в одному абзаці уявіть вміст 3-й дочірньої сторінки. Ви вставляєте посилання на цю третю додаткову сторінку. Текст цього посилання повинен містити опис предмета даної 3-й додаткової сторінки.

Далі йде текст, необхідний для часткового або остаточного розкриття змісту поточної сторінки.

Ви робите стільки H2, скільки у вас є дочірніх сторінок (сторінок третього рівня).

Рекомендується мати, як мінімум, 5 дочірніх сторінок на 1 материнську сторінку, отже у вас буде 5 заголовків H2.

В самому кінці сторінки вам необхідно організувати перелінковку між сестринськими сторінками - тобто сторінками одного рівня. Як правило, для цього організовують блок «На ту ж тему» або «Дізнатися більше» і проставляються анкорні посилання з розведеними ключами (або просто найменуванням сторінки) на найбільш близькі за змістом (або на всі) сестринські сторінки.

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

Зміст додаткових сторінок

Класична структура додаткової сторінки (сторінки 3 рівня) така.

H1 - заголовок сторінки, на якій ми знаходимося.

Далі йде вступний абзац, що розкриває тематику сторінки в декількох рядках. У цьому абзаці необхідно розмістити посилання з оптимізованим ключовим словом на батьківську сторінку (тобто сторінку першого рівня). Текст посилання (якір) буде містити головне ключове слово «материнської» сторінки.

Дехто ставить посилання не на сторінку-бабусю (сторінки першого рівня), а на материнську сторінку (сторінки другого рівня). Це теж є допустимим, в залежності від того де у вас розташовані блоки заклику до дії.

Інша частина контенту виглядає класично. Пишіть контент, розділяючи його на частини і структуруючи, використовуючи при цьому розмітку h2... h6. Додавайте медіа матеріали, списки, абзаци тощо. Створюйте зручний для читання і сприйняття контент.

Якість контенту має бути максимальною.

Внизу контенту знову зв'яжіть «сестринські» сторінки в блоці «Дивіться також» або «Матеріали на ту ж тему». Зверніть увагу, що ви можете пов'язувати не тільки «сестринські сторінки» (тобто не тільки сторінки 1.1., 1.2., 1.3,), але і сторінки, які мають іншого батька в межах кокона (тобто, наприклад, 2.1. , 2.2. або 2.4).

Ви можете інтегрувати в контент зовнішнє посилання, для підтвердження достовірності матеріалів. Розташовувати його слід в контенті після H2. Зовнішнє посилання повинно вести на сайт тієї ж тематики і надавати джерело додаткової інформації з даної теми.

Призначення сторінок семантичного кокона

Сторінки семантичного кокона, правильно перелінковані, з урахуванням семантичної близькості контенту, створюють дуже сильні зв'язки.

Батьківська сторінка (материнська/індексна/цільова сторінка) отримує вагу з дочірніх сторінок. Французи називають цей процес «висмоктуванням» змішаних сторінок.

Дочірня (змішана) сторінка виштовхує «батьківську» сторінку, при цьому «висмоктує» додаткові сторінки (Дочірні до неї) і зв'язується зі сторінками- сестрами.

Додаткові сторінки (внучки) вони «виштовхують» змішану сторінку (їхню мати) або батьківську сторінку і пов'язують між собою сторінки третього рівня (посилання між сестрами).

Приклад реалізації класичного кокона

Припустимо, ви є власником онлайн магазину з продажу взуття. Крім магазину на сайті є хороший блог з корисними статтями.

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

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

Наприклад, ми групуємо відміне взуття на сторінках нижчого рівня не за брендами і цінами, а за застосуванням. Тобто ми робимо сторінки для:

  • взуття для походів по горах - якщо наш відвідувач захотів стати альпіністом. Сторінки нижчого рівня цієї гілки можуть групувати і «продавати» взуття для високогір'я, або для подорожей по горах Криму, Карпат і ін.
  • взуття для походів по лісах - можливо відвідувач захотів зайнятися трекингом. Нижчі сторінки цієї гілки збирають і групують взуття для походів по лісах Полісся або вологих лісах з заболоченою місцевістю або по лісах Чернігівщини тощо.
  • взуття для зарубіжного туризму - можливо відвідувач хоче поїхати в Сахару і Антарктиду і ми групуємо взуття на сторінках нижчого рівня у вигляді взуття для походів по савані або взуття для Антарктиди, в кінці-кінців взуття для вилазок в гори Туреччини або для забігів з пірамід Єгипту.

Далі ми можемо підключити в кокон сторінки з інформаційними запитами, а також посилатися з кокона на якісь зовнішні корисні ресурси, наприклад за такими тематиками:

  • Ремонт і догляд за туристичним взуттям
  • Необхідні аксесуари для піших походів
  • Запобіжні заходи в походах
  • Як правильно вибрати розмір взуття
  • Як правильно сушити взуття в походах
  • Як уникнути травми ніг в походах
  • Цікаві маршрути для походів по Карпатах, Азії, Туреччини, Антарктиді
  • Посилання на туристичні клуби

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

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

Сучасні семантичні кокони

Семантичні кокони пройшли досить довгий шлях розвитку і вдосконалення. Класичні семантичні кокони побудовані на жорсткій ієрархії і вже потім на семантичних зв'язках контенту.

розкладка
Сайт, побудований на класичних семантичних коконах

Сучасні семантичні кокони вже не мають ні материнських, ні дочірніх сторінок, тобто сталася повна відмова від жорсткої «підлеглої» архітектури. Сучасні кокони засновані тільки на ретельно розрахованих семантичних зв'язках.

перелінковка
Сайт, побудований на семантичних зв'язках

Такі зв'язки досить важко розраховувати і створювати руками. І тому ми переходимо до вивчення концепції метамотів.

Що таке метамот

Метамот - це чергове поняття, розроблене і введене в обіг французькими оптимізаторами. По суті - це такі собі семантичні сутності, що складаються з декількох нероздільних лексик (слів-сигналів).

Ці лексики в сукупності утворюють сигнал, що дозволяє Google оцінити актуальність і відповідність контенту певної тематики. Використання лексик, розрахованих на основі даних видачі Google дозволяє створювати вкрай релевантні сторінки.

Крім того, лексики дозволяють спрогнозувати з достатньою достовірністю необхідну перелінковку - тобто вказати які сторінки з якою ми можемо пов'язати.

Більш того, для підвищення релевантності зв'язків поблизу анкорів необхідно використовувати власні лексики, тематичні лінки сторінок.

Отже, метамоти необхідні для:

  • написання релевантних текстів
  • для розрахунку найбільш ефективних зв'язків у семантичному коконі.

Метамоти ніяк не впливають на SEO, не є сигналом ранжування. Вони тільки дозволяють максимально оптимізувати структуру перелінковки і «доводять» Google, що наші внутрішні посилання максимально актуальні і релевантні.

Детальніше про теорію метамотів ви можете почитати на cocon.se, там же є кілька робочих прикладів.

Розглянемо один з них, присвячений життю гігантських панд в США.

список
Архів з розрахованим семантичним коконом про життя гігантських панд в США

Ми скачали демо архів кокона, розміром в 500 з гаком сторінок і тепер давайте подивимося що вдають із себе ці метамоти.

Відкриваємо будь-яку з розрахованих сторінок.

стрілки
приклад метамота

Перед вами приклад метамота, де є і редакційне завдання на створення контенту і розраховані сторінки, з якими необхідно залінкувати дану сторінку.

Тут:

  1. тематика поточної сторінки
  2. лексики, які потрібно вжити на сторінці (в розрахунку на 1000 слів)
  3. розраховані посилання, які потрібно ставити в певному місці контенту
  4. лексики, які потрібно вжити в абзаці з посиланням (15 слів до або після анкора посилання)

Власне, метамот цим не обмежується, там для кожної сторінки кокона даються рекомендації про те чи потрібно додавати зображення, відео або може бути посилання на вікіпедію.

Залишає це вам для самостійного вивчення на cocon.se.

Принципи семантичних зв'язків

Дві сторінки можуть бути пов'язані одна з одною, якщо деякі їх абзаци можуть доповнювати один одного. Сторінки не лінкуются, якщо контент цих сторінок розкриває одну і ту ж тему. Саме зміст повинен керувати перелінковкою, а не тематика.

Приклад: сторінка Моцарта може містити посилання на сторінку його рідного міста (Зальцбург). Але також необхідно, щоб на сторінці міста говорилося про те, що Моцарт народився в Зальцбурзі. Зверніть увагу, що тематики «композитор» і «місто» не збігаються, але сторінки доповнюють один одного за змістом.

Існує кілька правил використання метамотів. Наприклад:

  1. Серед розрахованих лексик для посилань, потрібно використовувати мінімум 3, найбільш природні.
  2. Посилання проставляються в одному абзаці разом з лексикою. Використовуйте в абзаці не більше 3-4 речень.
  3. Відстань між посиланнями і лексика обмежена. Це максимум 15 слів по обидві сторони від посилання.
  4. Ніщо не заважає мати 2 посилання в одному абзаці. Для цього вони повинні мати одні й ті ж лексики.
  5. Точні анкори на посиланні не приносять користі при перелінковці семантичного кокона. Враховується тільки контекст (частиною якого є анкор). Посилання - це якась обіцянка, дана користувачу про зміст контексту. Користувач повинен чітко зрозуміти, що знаходиться по ту сторону посилання.
  6. Посилання має бути націлене на конкретний абзац. Отже, використовуйте посилання-якоря (Посилання-якір - це звичайне посилання, в адресі якої використовується символ #, після якого йде ідентифікатор елемента. Ідентифікатор створюється за допомогою атрибута id у того тега, до якого треба перейти при натисканні на посилання.). Не змушуйте користувача читати всю цільову сторінку тільки для отримання додаткової інформації.

Висновок

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

Фото: flickr.com
Обробка: Vinci
Читати далі