"Filters" explained
It's not articulated brilliantly by the presumably non-technical chap, but here's what I understand their filtering to mean - as a professional Android developer.
1. You wish to know when things of particular interest to you have happened; let's say (a) receipt of an SMS that is intended for interpretation by your application, and (b) when a certain key sequence is pressed.
2. In order to do this, the application subscribes to the relevant system event (broadcast intents on Android). This is a general purpose subscription; in our scenario it is (a) receipt of any SMS, and (b) any key press.
3. Your application receives the events when they happen and has the responsibility of working out if they are relevant; in this instance, perhaps it is (a) does the SMS begin with some special sequence, and (b) do the recently recorded key presses still form any expected sequence? This is the 'filter' being described.
4. If it wasn't of interest, you drop the event and do no further processing. If it was, you respond appropriately; for instance hide the SMS from the user and perform its instruction as interpreted by the app logic.
Now, Carrier IQ have caused some degree of alarm by adding debug logging for all events at step 3, rather than those of relevance.
Unless you reverse engineer it or at least perform traffic analysis, you will never be sure that the app doesn't have some sleeper mechanism or make use of supposedly irrelevant data. One thing I can say is that if you persisted ALL of these events, you would significantly reduce the phone's responsiveness and eventually run out of storage.