пример данных нужен

То есть data.table по умолчанию использует одно ядро, но если в шапке скрипта прописать эту команду, то будет параллелить?

1. здесь написана непонятная конструкция. внутри join не считают, насколько мне известно.
2. все равно не понятно, нюансы в деталях, что именно надо считать.
3. есть классическая задача — подсчет числа уникальных пользователей в дневной развертке с момента старта приложения. в 99% случаев ее пытаются решать через вложенные циклы. это неэффективно и неправильно.
сдается мне, что и здесь что-то с постановкой и алгоритмикой не то.
4. retention в классической маркетологической трактовке — вещь очень расплывчатая. методика дожития — проще и честнее.

что-то похожее я недавно рисовал здесь https://habr.com/ru/post/555476/

сколько он использует по умолчанию — он показывает при старте.
можно самому проверить тоже

data.table::getDTthreads() # проверим доступное количество потоков
data.table::setDTthreads(0) # отдаем все ядра в распоряжение data.table
data.table::getDTthreads() # проверим доступное количество потоков

ооо, огромное спасибо! Было 6, стало 12

Могу названия столбцов написать, подойдёт?

Правильно ли я понял, что мне лучше создать справочник, с количеством первых открытий на каждую дату, а потом уже от туда джоинить?

сложно сказать, непонятна формула рассчитываемой метрики.
что до меня, то термин retention rate я вообще не понимаю. слова одни и те же, но каждый маркетолог подразумевает под ним что-то свое.
предпочитаю оперировать средним временем жизни.
Хорошая книга в аттаче.

Ну в моем случае, это процент тех кто пришел на 1...n день, от тех кто был в 0

это когортный анализ по сути, с одной когортой. по ссылке пример кода

Ну почти, только вместо когорт по дате , у меня 3 группы эксперимента в АБ тесте

какой-то такой принцип расчета

создание тестового набора

# генерируем данные на 15 недель
set.seed(42)

events_dt <- tibble(user_id = 1000:9000) %>%
  mutate(birthday = Sys.Date() + as.integer(rexp(n(), 1/10))) %>%
  rowwise() %>%
  mutate(timestamp = list(as_datetime(birthday) + 24*60*60 * (
     rexp(10^3, rate = 1/runif(1, 2, 25))))) %>%
  ungroup() %>%
  unnest(timestamp) %>%
  # режем длинные хвосты в прошлом и в будущем
  filter(timestamp >= quantile(timestamp, probs = 0.1),
         timestamp <= quantile(timestamp, probs = 0.95)) %>%
  mutate(date = as_date(timestamp)) %>%
  select(user_id, date) %>%
  setDT(key = c("user_id", "date")) %>%
  # оставим только уникальные по датам события
  unique()

подсчет динамики

# считаем для каждого пользователя "дату рождения"
users_dict <- events_dt[, .(birthday = head(date, 1)), by = user_id]

# а теперь считаем динамику числа уникальных пользователей
users_dict[, .(uN = .N), by = birthday][, cum_uN := cumsum(uN)]

а те, кто пришли в -1, -2 или 1, 2 день — они куда учитываются?

Ну у нас есть столбец retention_day, у нас каждый пользователь попадает в 1 из n дней

вопрос не про дату возврата, а про дату 1-го прихода. не все же в нулевой день пришли? они то как учитываются?

для ответа на эти вопросы  есть отлаженный аппарат survival analysis. Книгу для прикладного примера выше приложил.
Но маркетинг настойчиво пытается придумать наглядный паллиатив, зияющий методологическими дырами — в этом беда.

но если речь действительно идет про фиксированный день, названный нулевым, то методику подсчета я привел в коде выше.

спасибо, вот таким образом сделал, не много не так конечно как советовали)))

Почему вы используете head(date) который выводит первую запись, а не min (date) который выводит гарантировано минимальную, вне зависимости от сортировки

это принципиальный момент и гарантированный результат.
потому что однократная сортировка много быстрее сортировок в группах (а это и есть min).
setkey делает физическую сортировку
см. 3.4 What are primary and secondary indexes in data.table?, https://cran.r-project.org/web/packages/data.table/vignettes/datatable-faq.html#what-are-primary-and-secondary-indexes-in-data.table

Я вижу что вопрос решился уже.
но нет.  не подойдет. Когда хотите помощи - лучше прикладывать пример данных (сгенерированный - если у вас все секретно)

Гадать по описанию - плохая затея