IDGAF about "user retention." 

A better experience is just a very simple, clean, easy to understand UX that just works. I know how that should function at the user. The bank end stuff is what I don't know Jack about. 

A clean, simple, straightforward user interface will do the most to "keep users coming back."

You only need to stick to:
-automagic book lookup by title, author, barcode, or ISBN 
-automagic cover lookup for said titles, as an option. I know some don't care for the clutter of book covers in a clean list view.
-three lists: reading, to read, read
-ratings upon completion
-it's not hard, I guess, to also allow written reviews but I don't think that's necessary for a first iteration
-nostr connectability to the whole ecosystem, but specifically to be able to share links to books, reviews of books, and curate a separate list of connected npubs to "follow" and possibly another list of npubs to "push notifications to" when I book is finished/reviewed/added to the list "to read" list
-further iterations might include a user curated and "recommended list" that others can easily add to their "to read" list, in part or total

But at this point I really should be doing my fiat mining job instead of building out all the app features. 

My point is that I really don't care about concerns of retention. That's not at all a metric that matters to me, as a user.  

 As a creator of tools which I hope will bring value to those who use them, user retention is a useful measure of whether user received value enough to return. 

 How would you figure that out without being intrusive? (That's mostly a rhetorical question to get me to think about how I would do it.)

I'd rather use sats as an indicator. If people will pay for it, it's valuable. 

See my reply to one of Stella's notes.  

 Simplistically, if someone starts posting git events but then stops, then they havn't been retained. 

 So, if an npub goes dark. OK. That makes sense.