2
Какое максимальное количество настраиваемых событий вы можете сообщить за сеанс с помощью аналитики Flurry?Максимальное количество настраиваемых событий в аналитике Flurry?
A
ответ
5
Ограничение, по-видимому, 300 различных идентификаторов событий и, следовательно, 300 пользовательских событий. Цитирование: http://support.flurry.com/index.php?title=Analytics/GettingStarted/TechnicalQuickStart
Ваше приложение в настоящее время ограничивается подсчета вхождений 300 различных идентификаторов событий (максимальная длина 255 символов).
Addional details from here
Да, есть предел 300 событий для каждого приложения. Каждое событие может иметь до 10 параметров, и каждый параметр может иметь любое значение значений.
3
Я считаю, что она бесконечна:
Каждое событие может иметь до 10 параметров, и каждый параметр может иметь бесконечное число значений, связанных с ним. Например, для параметра «Автор» могут быть 1000 возможных авторов, которые написали статью . Мы можем отслеживать каждого автора через этот единственный параметр.
Так что, если у вас может быть бесконечное количество значений, у вас может быть 10 миллионов авторов. Поскольку все они являются просто значениями, каждый из них можно отслеживать (через параметр). Если они «могут отслеживать каждого автора через этот единственный параметр», то я не думаю, что ваш счет событий был бы смягчен. Это было бы предположить, вам настроить ваши типы событий должным образом, как и в их примере:
NSDictionary *articleParams =
[NSDictionary dictionaryWithObjectsAndKeys:
@"John Q", @"Author", // Capture author info
@"Registered", @"User_Status", // Capture user status
nil];
[Flurry logEvent:@"Article_Read" withParameters:articleParams];
Одно событие с максимум 10 словарных элементов, с бесконечным числом возможных значений ... Я думаю, что было бы с уверенностью сказать вам, здесь не ограничиваются.
+0
Как насчет того, что здесь сказано? Http: // ошибка.yoyogames.com/view.php?id=9314#c17516 – Phil
+0
@Phil Вы всегда можете связаться со своей линией поддержки. В отношении вашего сообщения: я предполагаю, что имена «300 событий» состоят из «200 событий и до 100 уникальных имен событий», которые были бы 300 заданными в ответе 0x7fffffff. Я не верю, что ответ разработчика исключит мой ответ. Кроме того, если вы действительно были обеспокоены, вы могли бы провести какую-то следственную работу самостоятельно и протестировать ее. – Firo
+0
Точно так же, как хэдз-ап, если вы пытаетесь отслеживать данные через воронку с помощью этого метода, это не будет работать изначально в Flurry. например Если у вас есть куча экранов, и вы пытаетесь увидеть, сколько экранов пользователи обычно проходят, у вас будет один из ваших параметров как «номер экрана». Но вы не можете выполнить встроенную воронку в Flurry на основе этого параметра. Вы можете использовать только последовательности последовательностей/пользователей, основанные на событиях. – rizzes
5
Количество событий, которые вы можете сообщить за сеанс в Flurry, равно 1000. Я задал этот вопрос поддержке Flurry, поскольку я не мог найти его в другом месте (и ни один из ответов здесь действительно не отвечает на вопрос).Они ответили, а также послал мне краткий документ под названием «Шквал Методология и Best Practices», который содержал, помимо всего прочего, это резюме:
- 300 уникальных событий в приложение
- 1000 событий макс за сеанс
- 100 уникальные имена событий на сессию
- 10 PARAMS максимума на событие
- ключ/значение для параметров должны быть строки
- длины ключа не более 255 символов
- Значение Максимальная длина 255 символов
В определении «сессии» важно, я цитирую, из того же документа:
Flurry аналитика базируется на сессии модели, которая только «телефоны дома» при запуске и фоновой сессии. Это предотвращает «talkiness» из SDK, экономит батарею, не всегда работает в радио и позволяет передавать данные путешествовать в согласованный пакет.»
(...)
Одно дополнение к модели сеанса Flurry это понятие, которое пользователь может скакать из приложения на очень короткое время и заново приложение и все еще быть в оригинальной сессии. время может быть установлено, в Millis, , который в просторечии называют «сессии Тайм-аут». это настраивается при запуске приложения (см setContinueSessionMillis для более деталей) в диапазоне от 5 секунд до 1 минута со значением по умолчанию 10 секунд. Если, когда пользователь возвращается в приложение, то «сеанс тайм-аут» не был превышен, то SDK будет относиться к «новым» сессиям как продолжение предыдущего сеанса.
При новом запуске, если есть какой-либо сессии не послали, они будут отправлены. В то же время SDK примет решение о том, будет ли или не продолжать сеанс или начать новый.
The document is here. поддержка Flurry послал его ко мне в конце февраля 2015.
1
Существует предел 300 событий для каждого приложения. Каждое событие может иметь до 10 параметров, и каждый параметр может иметь любое количество значений. Пожалуйста, проверьте все данные. here
Я думаю, что это немного отличается, это касается количества различных типов настраиваемых событий, которые вы можете использовать за сеанс, меня интересует, сколько общих пользовательских событий любого типа вы можете сообщить за сеанс. – Phil
Спасибо, но информация связывания еще не очень понятно, как они относятся к созданию событий, не сообщают событий, поэтому еще раз, что может означать, что вы можете создать 300 различных тип события, все из которых может быть отчетности во время сеанса , но меня интересует, сколько событий любого типа можно сообщить во время сеанса. Возможно, это 300 (хотя, похоже, это не так много), но это не ясно. – Phil
@Phil Вероятно, вы должны были сделать свой вопрос немного более ясным, если бы вы ожидали ответа, отличного от того, который дал вам 0x7fffffff. Мне кажется, он ответил на ваш вопрос. (+1 для ответа кстати). – Firo