Это уже простой коэф корреляции, но вопрос в том, что это даст: конечно, результаты будут зависеть от претеста, какое бы воздействие вы не сделали

Но если хотите учесть взаимодействие индивидуального претеста с экспериментальным воздействием, то посмотрите в сторону смешанных моделей (они везде по-разному называются, например, linear mixed effects models)

спасибо большое!

Работаю над задачей расчета суммы долга старше 90 дней. Возраста долга считаю по FIFO на основании транзакций. Данные выглядят так:
Date            |  Customer     | Amount| Note
——————————————————————-
01.01.2021 | AngryClient  |   1000     | invoice, Dt
15.01.2021 | AngryClient  |     -500    | payment, Cr
02.05.2021 | HappyClient |   2000     | invoice, Dt
15.05.2021 | HappyClient |   -1000    | payment, Cr

В итоге хочу получить отчет на выбранную дату 18.05.2021:
1. Total debt:                1500
2. Overdue debt 90+:   500

п1. Общий долг - простая сумма с фильтром по дате.
затрудняюсь, как подсчитать п2.

Проблема сравнить две даты ? Смотрите difftime()

В лоб нужно маркировать транзакции на погашенные и нет и формировать актуальный остаток для каждой транзакции.
Тогда овердю 90+ это сумма актуальных остатков с филтром по разнице дат

Вариантов масса.
0. Сортировка по шкале времени.
1. cumsum по транзакциям дает вектор баланса на даты платежей.
2. все записи маркируются как [0-90] или [90+] в зависимости от даты отчета (tag debt_type).
3. для каждого клиента берется последняя запись в группе (user_id, debt_type).

3 строки средствами data.table

на всю АБС-ку уйдет несколько секунд

как-то так (не запускал, просто написал)

dt[order(date), balance := cumsum(amount), by = customer] %>%
  .[, debt_type := date - Sys.Date() < 90] %>%
  .[, tail(.SD, 1), by = (customer, debt_type)]

Потом можно pivot_wider или data.table::dcast

спасибо большое, буду пробовать

Это не отвечает на вопрос. Там нужно понять что конкретная транзакция не загашена на 90 дней.

Вы смотрите долг на конкретную дату. Он может состоять из долга давностью 70, 80, 90 дней.

Еще как отвечает.
В каждой последней записи будет дата — ответ на вопрос "когда именно"

Я показал типовой каркас для задачи подобного типа. Дальше его можно обвешивать.
Но задача тривиальная и средствами data.table крутит миллионы пользователей за секунды. Проверено.

1. вопрос стоял про 90+.  какой вопрос — такой ответ.
2. это не единственный способ решить задачу, есть и другие подходы
3. мы же говорим про minimal reprex? тогда все лишнее в сторону.

вопрос был с учетом принципа FIFO) ну да ладно, нет репекс нет вопроса, действительно

так что не так?  
и причем здесь FIFO? FIFO вообще-то First In First Out — относится к очередям.
разве в кредитных организациях ввели очередь на погашение кредита (мы здесь же не изучаем очереди в сберкассе)?

у каждого пользователя своя ПЕРСОНАЛЬНАЯ стрела времени и она однонаправленная.
у него на дату либо погашен долг, либо нет — бинарное состояние (обещанный платеж не в счет).

можно отдельно группы делать и по типу платежа,
можно `rolling join`для приведения дат
можно различные типы задолженностей делать (корзинки).

в любом случае эта задача укладывается в 1-2 экрана кода

1. Непосредственно по вопросу. Наверное, что-то не так с указанием кодировки. Надо читать секцию Encoding в https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/connections .
Может надо указывать "native.enc". Это древняя функция и там все платформозависимое.
2. Не использовать write.table и использовать современные, понятные и кроссплатформенные библиотеки, пишущие в юникоде? write_delim
https://readr.tidyverse.org/reference/index.html

Ну ок.

Давайте формализуем.

По каждому заемщику есть 2 вида трнанзакций.
Он берет займ и его гасит. Пусть когда он берет займ транзакции отрицательные, а когда отдает - положительные.
В задаче нет ничего о том что перед тем как взять займ он должен погасить предыдущий.  

Иерархия погашения есть, она выраженна по принципу FIFO

ЧТо значит, что имея вектор вот таких транзакций

-500,-1000, 500 мы должны "погасить" первые -500 за счет третей транзакции.

Но нам интересно не только какие транзакции погашенны, а как давно не погашены. И в задаче явно указано что интересует просрочка только выше 90 го дня.

Ваш подход в явном виде этого не учитывает.

Например в для ситуации вида

   days tranz
  <dbl> <dbl>
1   -99  -500
2   -10 -1000
3    -1   500

Мы должгны придти к выводу что нет просрочки в 90 дней.
По принципу FIFO 500 рублей полученные - 1 день назад скомпенсировали -500  взятые -99 дней назад.

Предложенный подход с кумулятивной суммой ничего из этого не покажет.

А если например нет третьей транзакции, то мы должны получить по такому заемщику результат что просооченный долг старше 90 дней - 500

я полностью согласен, что в полной постановке задачи все гораздо сложнее.
но в текущем варианте нет правил выдачи кредита, пролонгации, ресета беспроцентных окон. точка отсчета не задана, последовательные платежи непонятное к чему относятся...

именно некий упрощенный макет задачи

по-хорошему, должны быть ФТ, чтобы это обсуждать. А так, мы просто обменялись мнениями по кодингу.

Большое спасибо, буду изучать! Сообщу, если удастся решить проблему

Да, в самом деле, помогло простое решение: fileEncoding = "native.enc". Спасибо большое за помощь!