Ціна — це не число на лендінгу. Це гіпотеза, яка потребує перевірки так само, як і сам продукт. У Web3 є свої механіки, але базова логіка залишається: хто платить, за що саме і чому ваша ціна вигідніша за альтернативу.
Чому ціноутворення в Web3 складніше, ніж здається
У традиційному SaaS ви працюєте з однією валютою та передбачуваними витратами. У Web3 додаються три складові, які здатні зруйнувати навіть продуману модель.
Перша — мультивалютність. Користувач може заплатити в нативному токені мережі, стейблкоїні або фіаті через платіжний шлюз. Кожен варіант має свої комісії, час обробки та конверсійні витрати.
Друга — волатильність. Якщо ваш сервіс коштує 10 SOL, то через тиждень це може бути еквівалентно як 700 доларів, так і 1400. Це неприйнятно для B2B-клієнтів, які планують бюджет, і незручно для рітейлу.
Третя — прозорість витрат. У Web3 користувач бачить газ-комісію окремим рядком. Він знає, що транзакція в мережі Solana коштує частки цента, тому пояснити високу підписку «інфраструктурними витратами» не вийде.
Четверта — порівняння з традиційними альтернативами. Ваш продукт конкурує не лише з іншими Web3-сервісами, а й із звичайними інструментами. Якщо ви робите CRM для NFT-проєктів, клієнт порівнюватиме вашу ціну з HubSpot чи Notion, а не лише з іншими блокчейн-CRM.
Методи ціноутворення
Cost-plus
Ви рахуєте всі витрати (сервери, RPC-вузли, команда, маркетинг) і додаєте маржу. Підходить для інфраструктурних сервісів із передбачуваним навантаженням: хостинг смарт-контрактів, індексери, API-шлюзи.
Обмеження: цей метод не враховує цінність для клієнта. Якщо ваш виторг покриває витрати з маржею 30%, але клієнт отримує економію в 10 разів більшу — ви недоотримуєте. І навпаки: якщо витрати високі, а цінність низька — продукт не продастися за такою ціною.
Value-based
Ціна базується на тому, скільки грошей клієнт заощаджує або заробляє завдяки вашому сервісу. Наприклад, якщо ваш інструмент автоматизує розподіл токенів і економить команді 20 годин на місяць роботи розробника — ви можете прив'язати ціну до вартості цих годин.
Це найбільш надійний метод для продуктів з високою доданою вартістю. Але він вимагає глибокого розуміння клієнтського контексту: ви маєте знати, скільки коштує помилка, затримка або ручна робота для вашого цільового сегмента.
Competitor-based
Ви орієнтуєтесь на ціни конкурентів і позиціонуєтесь відносно них: дешевше, дорого, те саме. Корисно на етапі швидкого орієнтування, але небезпечно як єдиний метод.
У Web3 конкурентів може не бути взагалі, або вони можуть субсидіювати ціну за рахунок токеноміки (що ви не можете собі дозволити без відповідного фінансування). Копіювання такої ціни — прямий шлях до збитків.
Market-based
Ви визначаєте ціну через готовність ринку платити. Проводите опитування, інтерв'ю, спостерігаєте за поведінкою. Це не «скільки хочуть платити» — це аналіз реальних транзакцій і конверсій за різними ціновими точками.
Найкраще працює в комбінації з value-based: ви знаєте цінність і перевіряєте, чи готовий ринок за неї платити.
Специфіка ціноутворення на Solana
Оплата в SOL, USDC, фіат — що пропонувати
USDC на Solana — найбезпечніший вибір для ціноутворення. Стейблкоїн усуває проблему волатильності, і ви можете встановити фіксовану ціну в доларовому еквіваленті. Для B2B-клієнтів це часто єдиний прийнятний варіант, оскільки вони звітують у фіаті.
SOL підходить для рітейл-аудиторії, яка вже тримає нативний токен і не хоче додаткових конверсій. Але ціну в SOL доведеться перераховувати регулярно або прив'язувати до оракула — інакше ви втрачаєте на волатильності.
Фіат через платіжний шлюз (Stripe, MoonPay та подібні) розширює аудиторію на тих, хто не має криптогаманця. Але додаткові комісії шлюзу (зазвичай 2–5%) або лягають на клієнта, або зменшують ваш маржинальний дохід. Прозоро показуйте, хто несе цей витрат.
Практичний підхід: встановіть базову ціну в USDC, додайте опцію оплати в SOL за поточним курсом через оракул і пропонуйте фіат як зручну альтернативу з відображенням комісії шлюзу.
Волатильність криптовалют та її вплив на ціни
Якщо ви приймаєте волатильні активи, у вас є три стратегії захисту:
- Автоматична конверсія. Отримали SOL — одразу перевели в USDC через DEX або CEX. Мінімізує ризик, але додаткова транзакція коштує час і комісію.
- Часткове хеджування. Залишаєте частину в нативному токені для операційних потреб (газ, стейкінг для RPC-вузлів), решту конвертуєте.
- Динамічне ціноутворення. Ціна в SOL оновлюється при кожному відкритті сторінки оплати. Користувач бачить актуальний курс, але може роздратуватися, якщо ціна «стрибнула» за хвилину.
Що б ви не обрали, прямо вказуйте механізм на сторінці оплати. Нечіткість тут руйнує довіру миттєво.
Як тестувати ціну
A/B тестування
Показуйте різним групам відвідувачів різні цінові точки і вимірюйте конверсію в оплату. У Web3 це ускладнено: користувачі можуть обговорювати ціну в спільноті, і «витік» варіантів зруйнує чистоту експерименту.
Пом'якшення: тестуйте не на лендінгу, а всередині продукту — на етапі активації платної функції. Або сегментуйте за географією та каналом залучення, щоб зменшити перетин аудиторій.
Мінімальний обсяг даних: не робіть висновків на основі 10–20 транзакцій. Для статистично значущого результату потрібні сотні відвідувачів на варіант.
Експерименти з тарифами
Замість тестування окремих чисел, тестуйте структуру тарифів. Наприклад:
- Два тарифи проти трьох тарифів (чи потрібен «професійний» середній?).
- Оплата за використання проти фіксованої підписки (яка модель дає вищий LTV — довічну цінність клієнта).
- Безкоштовний тираж проти безкоштовного періоду (що краще конвертує у платного клієнта).
Фіксуйте не лише конверсію, а й відтік: дешевий тариф із високою конверсією, але з відтоком 80% за місяць — гірший за дорожчий із відтоком 10%.
Ціноутворення для різних сегментів
Ретейл vs. інституційні клієнти
Ці два сегменти вимагають принципово різного підходу — і не лише в ціні, а й у форматі пропозиції.
Ретейл-користувачі чутливі до ціни, приймають рішення швидко, очікують прозорості і не підписують довгі контракти. Для них працюють: низький поріг входу, оплата за використання, місячна підписка без зобов'язань, знижки за річну передоплату.
Інституційні клієнти (фонди, маркетмейкери, великі проєкти) чутливі не до ціни, а до ризику. Їм потрібні: SLA (угода про рівень сервісу), виділена інфраструктура, пріоритетна підтримка, юридична ясність. Ціна тут формується через RFP (запит пропозицій) і переговори, а не через прайс на сайті.
Поширена помилка — пропонувати інституціям «рітейл-прайс зі знижкою». Це знецінює пропозицію. Замість цього створюйте окремий enterprise-тариф із іншим набором зобов'язань з обох боків.
| Критерій | Ретейл | Інституції |
|---|---|---|
| Чутливість до ціни | Висока | Низька (чутливість до ризику) |
| Цикл прийняття рішення | Хвилини — години | Тижні — місяці |
| Формат оплати | Підписка, pay-per-use | Кастомний контракт, річні угоди |
| Ключовий аргумент | Дешевше за конкурентів | Надійність, SLA, відповідність вимогам |
| Валюта | SOL, USDC, фіат | Зазвичай фіат або USDC з інвойсом |
Типові помилки ціноутворення
Ціна «як у конкурентів» без розуміння їхньої економіки. Конкурент може субсидіювати продукт через токеноміку, мати інше джерело доходу або навмисно працювати у збиток для захоплення ринку. Копіювання такої ціни без тієї ж бази — пряма втрата грошей.
Ігнорування газ-комісій у собівартості. Якщо ваш сервіс робить багато транзакцій від імені користувача (наприклад, пакетне minting або розподіл), ці транзакції коштують гроші. Навіть на Solana, де комісії мінімальні, при масштабі у тисячі операцій це стає помітною статтею витрат.
Фіксація ціни в SOL без механізму перерахунку. Якщо ви встановили ціну «5 SOL за місяць» і не перераховуєте її, то за рік реальна вартість підписки для вас може змінитися в кілька разів. Це не ціноутворення — це гра в рулетку.
Заниження ціни «для зростання аудиторії». Безкоштовний або символічний тариф приваблює користувачів, які не готові платити взагалі. Ви витрачаєте ресурси на обслуговування людей, які ніколи не стануть платними. Краще мати 100 платних клієнтів за 50 доларів, ніж 10 000 безкоштовних, з яких конвертуються троє.
Одна ціна для всіх. Ретейл-користувач, який робить 10 транзакцій на місяць, і трейдинг-фірма, яка робить 10 000, не можуть платити однаково. Pay-per-use або градація тарифів за обсягом — не жадібність, а базова справедливість, яка зберігає обох клієнтів.
Забуття про операційні витрати прийому платежів. Платіжні шлюзи, конверсія через DEX, вивід на фіат — усе це має комісії. Якщо ваша маржа 15%, а шлюз бере 3%, ви втрачаєте п'яту частину прибутку ще до оподаткування. Рахуйте повну собівартість прийому кожного типу платежу.
Наступний крок після визначення ціни — донести її до ринку. Як побудувати стратегію go-to-market для Solana-продукту, описано в наступному розділі.