A changelog is not release notes. Release notes describe what changed in the software; a changelog tells a specific customer that the thing they complained about is now fixed. Only the second one affects renewal.
Write the outcome, not the ticket
'Refactored the export pipeline' means nothing to a customer. 'CSV exports over 100k rows now finish in seconds instead of timing out' names the pain they reported.
One entry per user-visible outcome. Bundle the eleven commits behind it and never publish an entry a non-technical user cannot parse in one read.
Notify the people who asked
The highest-value moment in a feedback loop is the email that says 'you requested this in November, it shipped today.' It costs nothing and it is the most-forwarded message your product sends.
This requires your changelog to be linked to the original requests, not written separately in a marketing tool.
Publish on a rhythm
Weekly or biweekly beats continuous. A predictable cadence trains customers to read it; a firehose trains them to ignore it.
Keep an archive with permalinks. Sales links individual entries into deals, and support links them into tickets.
Measure it
Track opens on the notification, views on the entry, and reactions. A feature with high views and low reactions usually shipped without the part that mattered.