Apply suggestions from code review

Co-authored-by: stayseesong <[email protected]>

Author: ashton-huxtable

src/guides/filtering-data.md

@@ -80,7 +80,7 @@ The events filtered out of individual destinations using this method still arriv
 
 **Integration filters are all-or-nothing for each event.** If you require more detailed control over which events are sent to specific destinations, you can use Destination Filters to inspect the event payload, and conditionally drop the data or forward it to the destination.
 
-**Integration filters will not override an existing value in the integrations object.** If the integration object already has a value for the integration, the per source schema integration filters will not override this. For example, if you are sending events to Appsflyer with the appsflyerId passed into the integration object:
+**Integration filters won't override an existing value in the integrations object.** If the integration object already has a value for the integration, the per source schema integration filters will not override this. For example, if you're sending events to Appsflyer with the `appsflyerId` passed into the integration object:
 
 ```javascript
 integrations: {
@@ -89,7 +89,7 @@ integrations: {
   }
 }
 ```
-And for the same event you have Appsflyer turned off using the per source schema integrations filter, this filter will not override the above object with a false value, and events will still send downstream. In this scenario, [destination filters](#destination-filters) can be used to drop the event before it is sent downstream. 
+For the same event you have Appsflyer turned off using the per source schema integrations filter, this filter won't override the above object with a false value, and events still send downstream. In this scenario, [destination filters](#destination-filters) can be used to drop the event before sends downstream. 
 
 ## Schema event filters