Announcing PYLON 1.7 - Introducing Interaction Filter Swapping

Richard Caudle | 2nd March 2016

Today we released version 1.7 of PYLON for Facebook Topic Data. This release includes some key features that will make it easier for you to build production solutions with PYLON.

Introducing interaction filter swapping

Until now recordings and indexes have been tied to the CSDL you defined for your filter. When you compiled your CSDL you received a hash, which in turn was used as the identifier for the index in which recorded data was stored. This meant that if you wanted to update the CSDL for your filter, this would result in a new hash and a new separate index for the recorded data.

This limitation has made it difficult for some customers to build solutions for dynamic use cases. For example, if you wanted to record audiences discussing the latest movie releases, you would need to update your filter for new movies as they are released, resulting in multiple indexes you would need to combine for your analysis.

In this release we've introduced the ability to update your interaction filters for running recordings. You can use the pylon/update endpoint to update a running filter. Recordings and indexes are now identified by id rather than the hash for the CSDL definition.

We will be publishing a blog post showing you a worked example in the next couple of days.

Further tokenized targets for query filtering

Another improvement we've made in this release is tokenization of further targets for use in your query filters.

You'll already be aware that you can use query filters to take a subset of your index for analysis. For example you could analyze only stories that share links to the New York Times using a query filter:

links.domain in "" AND fb.type == "story"

We've now added tokenization for more targets so you can use advanced operators such as contains_any in your query filters. You can now be more precise with your query filters, for example you could analyze only stories that share links to the New York Times travel section:

links.url contains "" AND fb.type == "story"

As link URLs are now tokenized the contains_any operator will match links to the travel section as effectively in this case a substring match is performed.

Move to API version 1.3

In order to introduce ids as the identifier for PYLON recordings rather than hashes, we've introduced a new version of our API.

The new API version is 1.3. You can read more about the API changes in our API changelog. All of our official client libraries have been updated to support version 1.3 of the API.

As a quick example, until now if you'd wanted to retrieve details of a recording you would have called the pylon/get endpoint providing the hash for your recording. With version 1.3 of the API you would use the recording id instead:

curl -X GET 
    -H 'Authorization: username:api_key'

Or in Python:

from datasift import Client
datasift = Client("your username", "identity API key")
datasift.pylon.get([id for your recording])

Read our migration blog post for more details.

You can continue to use the version of the API you are currently using and move to v1.3 when you are ready. Deprecation dates for API versions are listed on the API changelog.

Note that updating of interaction filters is only supported in version 1.3 of the API. So to use this feature you will need to move to the latest API.

Previous post: Using Facebook Topic Data to Refine an Advertising Campaign

Next post: Planning Your Migration from API v1.2 to v1.3