Filtered index statistics refresh threshold
You've got two questions in here:


  Is the above data sufficient information to base an index rebuild
  decision upon or would I need to have additional metrics involved?


One missing link is the size of the index.  If you're talking about an object with less than, say, 1000 pages, then index rebuilds aren't all that critical.

Another missing link would be the churn of the index.  Typically I see filtered indexes used when they're a very, very small subset of the entire table, and the subset changes fast.  Guessing by the name of your filtering field (OfferStatus = 0), it sounds like you're indexing just the rows where you haven't made an offer yet, and then you're going to immediately turn around and make an offer.  In situations like that, the data's changing so fast that index rebuilds usually don't make sense.


  Or, for filtered indexes do we even care about fragmentation and
  should just explicitly update statistics at X interval?


SQL Server updates stats on objects when ~20% of the data changes, but filtered indexes &amp; stats are a special case.  They're also updated when 20% of the data changes - but it's 20% of the base table, not 20% of the filtered subset.  Because of that, you probably want to manually update stats on them periodically.  I love Ola Hallengren's maintenance scripts for this - the index maintenance stored proc has a parameter for updating statistics, and another parameter for choosing what level of sampling you want, and another parameter for choosing whether to update stats on all objects or only the ones with changed rows.  It's fantastic.