--- title: "Чому картки клієнтів змішуються?" description: "Пояснення трьох ситуацій, коли на одній картці опиняються дані різних людей, і чим вони відрізняються між собою." --- # Чому картки клієнтів змішуються? Картка клієнта задумана як одна людина з усіма її каналами. Але інколи в неї потрапляє чуже: два різні Telegram-акаунти під одним записом, контакт, який насправді належить сусідній картці, або діалоги, що лишилися прив'язаними до старого власника. Оператор відкриває таку картку і бачить суміш двох історій. Ця стаття пояснює, звідки береться така суміш, які три ситуації розрізняє платформа і чому для кожної підходить своя дія. --- ## Контекст і проблема Платформа прив'язує нове звернення до наявної картки за збігом телефону, email або юзернейма — саме це дає корисну кросканальність, коли одна людина пише з Telegram, пошти й віджета, а картка лишається одна. Докладніше про сам механізм — у статті [Чому в одного клієнта багато каналів](/uk/broadcastusers/explanation/why-one-client-many-channels.md). Та сама логіка інколи спрацьовує ширше, ніж треба: - у сім'ї або в компанії кілька людей користуються одним номером телефону чи однією поштою; - людина змінила акаунт у месенджері, а старий лишився активним; - дані переносили з попередньої системи, і частина карток приїхала без прив'язки до бота; - оператор об'єднав дві картки вручну, помилившись у збігу. Наслідки видно не одразу, а в роботі: оператор відповідає, спираючись на чужу історію; звіти рахують двох людей як одну; розсилка йде на контакт, який цій людині не належить. --- ## Три ситуації, які платформа розрізняє Платформа регулярно сканує базу й формує **кейси** — конкретні місця, де щось переплуталось. Кожен кейс має **клас проблеми**, і саме клас підказує, що з ним робити. ### Кілька акаунтів на картці На одній картці зібралися контакти, які майже напевно належать різним людям: наприклад, два різні Telegram-акаунти в межах одного бота. Історія обох людей злилася в одну стрічку. Тут картка одна, а людей у ній двоє або більше. Розв'язання — витягнути зайве назовні. ### Чужий контакт Контакт сидить на картці, якій не належить: його повідомлення насправді стосуються іншої, вже наявної картки. Тобто «дім» для цього контакту вже існує, просто він живе не за адресою. Це найтонший із трьох випадків, бо тут можливі два різні прочитання. Якщо це та сама людина — картки варто звести докупи. Якщо люди різні — зводити не можна, треба перенести лише сам контакт. ### Чужі діалоги Контакти вже стоять правильно, а от частина діалогів лишилася прив'язана до картки, яка більше не є їхнім власником. Такий «хвіст» зазвичай тягнеться з часів попереднього об'єднання чи перенесення. Тут чіпати контакти не потрібно взагалі — рухати треба тільки самі розмови. --- ## Чому дії різні, а не одна універсальна Спокусливо мати одну кнопку «полагодити». Ми свідомо цього не робимо: три ситуації відрізняються не обсягом, а напрямком — у першій дані виїжджають із картки, у другій переїжджають між картками, у третій рухаються лише розмови. Одна дія на всі випадки означала б, що в частині кейсів вона робить забагато. Тому в кейсі пропонується тільки те, що має сенс для його класу: | Клас проблеми | Що пропонується | Чому саме це | |---|---|---| | **Кілька акаунтів на картці** | **Відокремити контакт(и)** | Другу людину треба винести з картки — у нову або в іншу наявну. | | **Чужий контакт** | **Перенести контакт власнику** (рекомендовано) або **Обʼєднати картки** | Перше — коли люди різні. Друге — коли це справді одна людина. | | **Чужі діалоги** | **Перенести діалоги власнику** | Контакти вже на місці, переїжджають лише розмови. | Для класу **Чужий контакт** платформа позначає перенесення як **Рекомендовано** і показує попередження перед об'єднанням: об'єднання забирає **всю** картку-джерело цілком — усі її контакти, діалоги й канали. Якщо картка насправді належить іншій людині, це склеїть двох людей замість того, щоб їх розділити. Перенесення ж торкається рівно того, що ви обрали. --- ## Що платформа гарантує під час розбору **Спершу превʼю, потім зміни.** Кожна операція проходить майстер із кроками **Огляд**, **Що переїде**, **Конфлікти полів** (тільки для обʼєднання) і **Результат**, а перед виконанням відкривається окреме вікно **Підтвердіть операцію**. До цього підтвердження в базі не змінюється нічого — і цей факт написаний просто біля кнопки: «Нічого ще не змінюється — спершу превʼю». **Операція незворотна.** Діалог підтвердження каже це прямо: «Операція незворотна.» Скасувати виконану операцію в один клік не можна — саме тому перед нею показують точні числа, а не оцінку. **Усе записано.** Кожна виконана операція потрапляє в **Журнал операцій** із виконавцем, часом і знімком стану до неї. Крім того, у стрічці кожного зачепленого діалогу з'являється службова позначка про перенесення — оператор бачить, що розмова змінила картку, і не сприймає це як збій. **Історична статистика лишається на місці.** Закриті діалоги в звітах не переатрибутовуються: вони лишаються за тією карткою, якій належали на момент закриття. Це навмисне рішення — інакше кожен розбір заднім числом переписував би вже здані звіти. **Є стеля обсягу.** Дуже великі операції платформа не виконує, а відхиляє з повідомленням «Обсяг операції перевищує допустимий ліміт». Це захист від однієї необережної дії, що перемішає тисячі рядків. Такий кейс розбирають частинами або звертаються до адміністратора. **Картки різних ботів не об'єднуються.** Спроба зупиняється з поясненням «Обʼєднання карток різних ботів заборонено»: спільна картка на два боти зламала б і права доступу, і звітність. --- ## Самовиліковні кейси Частина знайдених кейсів не потребує втручання: вони розсмокчуться самі, щойно людина напише наступного разу і платформа перепривʼяже контакт. Такі кейси позначені як **Самовиліковні** й за замовчуванням у списку приховані — на плитці видно їхню кількість із підписом «приховано». Це зроблено навмисно: список має показувати роботу, а не всі відхилення поспіль. Решта кейсів — на сусідній плитці **болючих**, підписаній «потребують дій» — саме з ними й працюють. --- ## Наслідки для роботи команди **Розбір — не щоденна рутина.** Кейси накопичуються повільно. Розумний ритм — переглядати список після сканування раз на тиждень або коли оператори поскаржилися на чужу історію в картці. **Починайте з класу, а не з номера.** Клас проблеми одразу каже, наскільки кейс болючий: «Кілька акаунтів на картці» псує роботу оператора просто зараз, «Чужі діалоги» — переважно статистику. **Не поспішайте з об'єднанням.** Якщо ви не впевнені, що це одна людина, відкрийте переписку кнопкою **Переглянути переписку** просто в майстрі. Дві хвилини читання дешевші за незворотне склеювання двох людей. **Доступ поки лише для root.** Розділ розбору бачить тільки користувач **root**: операції переписують картки незворотно, тому на час розкату доступ навмисно не видається жодній іншій ролі — відповідного чекбоксa в налаштуваннях ролей немає. Якщо розділу не видно, зверніться до власника інстансу. --- ## Пов'язані матеріали - [Як знайти змішані картки клієнтів](/uk/broadcastusers/how-to/scan-mixed-client-cards.md) - [Як розібрати кейс і застосувати операцію](/uk/broadcastusers/how-to/untangle-client-card-case.md) - [Як перевірити журнал операцій](/uk/broadcastusers/how-to/check-card-operations-journal.md) - [Чому в одного клієнта багато каналів](/uk/broadcastusers/explanation/why-one-client-many-channels.md) - [Розділи картки клієнта](/uk/broadcastusers/explanation/client-card-sections.md)