Дозвольте провести вас через один реальний акаунт, від початку до кінця, замість опису бічної панелі пункт за пунктом. Скажімо, це фрилансер на першому тижні на платформі, який будує застосунок для відстеження звичок для невеликого клієнта. Ось що відбувається з цією збіркою в міру її руху дашбордом, у тому порядку, в якому це справді відбувається — і де кожна зупинка або допомогла, або витратила п'ять хвилин даремно.
Промпт
Вони відкривають AI Builder і вводять щось на кшталт «збудуй мені трекер звичок». Це розумне перше речення і поганий фінальний промпт. Те, що повертається, — не код, а план звичайною мовою, і якщо зупинитися на «виглядає нормально» й натиснути «схвалити», отримаєш щось технічно відповідне словам «трекер звичок» і загальне в усьому, що має значення. Клієнт фрилансера хотів без соціальних функцій, лише локальне сховище, темну тему за замовчуванням. Нічого з цього не було в першому промпті. Натомість це потрапляє в план у вигляді трьох правок перед схваленням: викреслити функцію «поділись своєю серією», яку план вигадав сам, замінити рядок про сховище, перемкнути тему за замовчуванням. Тридцять секунд редагування. Збірка, що виходить на іншому кінці, відповідає брифу, а не слову «трекер звичок».
Крок із планом, який люди пропускають
Я бачив, як саме цей момент іде не так в інших користувачів — схвалити перший план без читання, дійти до третьої ітерації й почати заново пояснювати обмеження, які мали бути задані ще на етапі плану. Крок із планом існує саме для того, щоб цього не сталося. Він коштує майже нічого, і це єдиний момент у циклі, де ти домовляєшся з агентом своєю мовою, а не налагоджуєш його вивід у коді.
Де насправді опиняється збірка
Після генерації трекер звичок з'являється як картка в Моїх збірках — сторінці бібліотеки з фільтрацією за типом, і це та сторінка, яку цей фрилансер відкриватиме частіше за будь-яку іншу вже до третього тижня, коли назбирається п'ять-шість збірок. Вона не з'являється у Вітрині; ця сторінка кураторська, а не автоматична, і клієнтська збірка, яка там не з'являється без анонсу, — правильна поведінка за замовчуванням. Вона також не з'являється в Шаблонах, якщо фрилансер не подумає зберегти її як шаблон — а варто, до речі, оскільки скелет трекера звичок — це саме те, що фрилансер перебудує для наступного клієнта з іншим брендингом. Більшість людей не відкривають «зберегти як шаблон» аж до шостої збірки, шкодуючи, що не зробили цього ще на першій.
Опубліковано, чи щось серйозніше
Тепер питання дистрибуції. Три реальні варіанти, а не один варіант із трьома назвами. Published дає безкоштовний субдомен, живий за секунди, без налаштувань — правильний вибір, поки клієнт ще розглядає й може попросити редизайн. Domain Management — для того моменту, коли власний домен клієнта готовий на це вказувати, і цей крок виконує подвійну роботу: підключення домену тут — не лише зміна URL, це також те, що дає аналітичним сторінкам далі в бічній панелі щось, до чого прив'язатися. Deploy, у налаштуваннях, — це шлях SFTP для випадків, коли клієнт наполягає, щоб збірка працювала на інфраструктурі, яку він контролює — більше налаштувань, і фрилансер більше не відповідає за безвідмовність, а це реальний компроміс, який варто усвідомлювати явно, а не виявляти випадково.
Для цієї збірки спершу Published. Перехід від субдомену до власного домену пізніше — не подія. Скасування розгортання на власному домені в клієнтському проєкті, який скасовують, — це більше прибирання, ніж воно того варте — і фрилансер, власне, уже обпікався саме на цьому в попередньому проєкті, звідси й звичка «за замовчуванням Published».
Відступ до магазину застосунків
Цей конкретний клієнт також хотів лістинг у магазині застосунків, тож збірка проходить через Shipped замість того, щоб зупинитися на Published — сторінку, яка існує тому, що перевірка в магазині асинхронна так, як веброзгортання просто не буває. Подай в один магазин — і воно чекає два дні; подай в інший — і пройде за двадцять хвилин. Shipped — це місце, де відстежуєш це без п'яти вкладок браузера з п'ятьма різними консолями магазинів, кожна зі своїм логіном і своєю термінологією статусів.
Порожня сторінка, про яку ніхто не попередив
Через тиждень після підключення домену фрилансер відкриває Search Performance, щоб перевірити. Порожньо. Навіть трохи сумно виглядає — жодного графіка, жодної цифри, лише запит на підключення акаунта. Це не поломка, це чесність: даних ще немає, бо Search Performance, Google Analytics та Store Analytics усі прив'язані до підключення акаунта Google в налаштуваннях, і жодна з них не заповнює історію заднім числом. Синхронізація починається з моменту підключення й лише вперед. Підключи домен першого дня — і матимеш тиждень історії на другому тижні; підключи його на десятий день, бо забув, — і почнеш з нуля на десятий день. Фрилансер підключив домен, але не акаунт Google — два окремі кроки, які виглядають так, ніби мали б бути одним.
Тут насправді коштує не відсутній графік. А те, що агенти оптимізації читають з тих самих даних, і агент, якого просять покращити рейтинг сторінки без жодної історії Search Performance за плечима, працює на основі загальних найкращих практик, а не реальних показників цього сайту. Пропущене підключення не просто залишає порожньою сторінку дашборду — воно обмежує можливості агентів.
Бриф, що з'являється непрошено
Через два тижні в Discovery з'являється картка: бриф можливості, що вказує на прогалину контенту на сайті клієнта, з прикріпленою кнопкою «Побудувати це». Справді корисно, коли влучає в щось, на що ви й так би відреагували. Але Discovery за задумом орієнтований на обсяг, а не на точність — брифів більше, ніж хтось встигне опрацювати — тож правильна позиція — це вхідна скринька пропозицій, а не черга на очищення. Фрилансер переглядає це раз на кілька днів і ігнорує більшість, що і є задуманим використанням, а не невстиганням.
Налаштування, які мали б статися першого дня
До цього моменту фрилансер торкнувся чотирьох сторінок налаштувань, жодного разу навмисно не відкривши меню налаштувань — кожну виявлено тому, що щось інше було порожнім.
| Сторінка | Що це виявилося регулювати |
|---|---|
| Google Accounts | Search Performance, Google Analytics та дані обґрунтування для агентів — одне підключення, три поверхні |
| Розгортання | Цілі SFTP, потрібні лише для шляху з сервером під контролем клієнта |
| AI-медіа | Стандартні налаштування генерації зображень, що використовуються всередині збірок |
| Тарифи та кредити | Ліміт використання, пакети кредитів, квитанції |
Google Accounts — це те, що варто налаштувати заздалегідь. Це єдина точка підключення, що стоїть за трьома окремими розділами дашборду, і дізнатися про це на власному досвіді — три різні порожні сторінки, три різні моменти «ой, треба щось підключити» — це саме та плутанина, якої дозволяє уникнути п'ятихвилинне налаштування в перший день.
Дві речі, які були поруч весь цей час
Плаваюча кнопка Ask-AI знаходилася на кожній з цих сторінок весь цей час, і це не спрощений FAQ-бот — він може підключити акаунт, запустити збірку або пояснити, чому сторінка порожня, від вашого імені. Клієнту фрілансера, який не розмовляв англійською, потрібен був увесь інтерфейс іншою мовою для дзвінка з переглядом; глобус у навігації перемикає всі двадцять мов прямо під час сесії, не втрачаючи поточну збірку. Жодну з цих речей не треба було відкривати методом проб і помилок, як усе інше в цьому огляді. Вони просто були там.
Це чесний підсумок перших двох тижнів з цим акаунтом — не «спочатку читай документацію, потім створюй», а навпаки. My Builds було абстракцією, доки в ньому не з'явилася картка. Search Performance було порожнім станом, доки домен не почав постачати дані. Читати мапу перед першою збіркою — непогана фонова підготовка, але ця мапа має сенс лише тоді, коли десь у ній вже є реальний трекер звичок.
