I created this ticket to discuss whether special mute events should been captured in `prefupdate` table.
AHT team launched special mute feature, which can mute users through special mute page. Before that user only can mute others on user's preferences page. Both ways change user's mute preference from user's perspective.
**The interfaces of these two pages.**
- snapshot of special mute
{F32197952}
- snapshot of mute by preference setting
{F32197949}
Now special mute events are stored in `event.specialmutesubmit`, which will be removed after 90 days. We don't have data about it after 90 days. Mute events from preference page are stored in `prefupdate` table, which will be sanitized after 90 days. We don't have user level information after 90 days, but we still can count how often it was used in history.
Should special mute events also been captured in `prefupdate` table as it's a change for user preference? Benefits include: same type of setting changes is stored in the same table; we don't lose historical data of special mute.
**Dataset**
From the timestamp we can tell the events in `specialmutesubmit` is not in `prefupdate`
- data from `prefupdate` table
{F32197912, size=full}
- data from `specialmutesubmit` table on the same day
{F32197946, size=full}
```
# SQL for prefupdate
SELECT *
FROM event_sanitized.prefupdate
WHERE year = 2020 AND month = 8 AND day=1
AND array_contains(array(event.property),'echo-notifications-blacklist')
#OR
SELECT *
FROM event.prefupdate
WHERE year = 2020 AND month=8 and day =1
AND substr(dt,1, 18) ='2020-08-01T03:49:2'
#SQL for specialmute
SELECT *
FROM event.specialmutesubmit
WHERE year = 2020 AND month=8 and day =1
```
Other ticket about `prefupdate` table might be related to this discussion: https://phabricator.wikimedia.org/T260867