README updates covering PII and queues

README.md

@@ -129,6 +129,8 @@ The `dfe:analytics:install` generator will also initialize some empty config fil
 | `config/analytics_pii.yml`       | List all fields we will obfuscate before sending to BigQuery. This should be a subset of fields in `analytics.yml` |
 | `config/analytics_blocklist.yml` | Autogenerated file to list all fields we will NOT send to BigQuery, to support the `analytics:check` task          |
 
+**It is imperative that you perform a full check of those fields are being sent, and exclude those containing personally-identifiable information (PII) in `config/analytics_pii.yml`, in order to comply with the requirements of the [Data Protection Act 2018](https://www.gov.uk/data-protection), unless an exemption has been obtained.**
+
 ### 5. Check your fields
 
 A good place to start is to run
@@ -161,6 +163,20 @@ models so that they are effective everywhere. A standard Rails application will
 have all controllers inheriting from `ApplicationController` and all models
 inheriting from `ApplicationRecord`, so these should be a good place to start.
 
+### 7. Configure queues
+
+Events are sent to BigQuery by your application's queueing backed via its ActiveJob adapter.
+
+Events are generated on each web request and database insert/update/delete query. Depending on the architecture of your application, potentially many jobs could be enqueued as users interact with your application.
+
+Consider how this may impact the processing of the other jobs in your application. You may wish to consider setting a custom queue name in `config/initializers/dfe_analytics.rb`:
+
+```ruby
+DfE::Analytics.config.queue = :default
+```
+
+Alternatively you may consider setting the priority of the jobs according to your chosen ActiveJob adapter's conventions.
+
 #### Controllers
 
 ```ruby
@@ -257,6 +273,7 @@ To reimport just one entity, run:
 bundle exec rails dfe:analytics:import_entity[entity_name]
 ```
 
+
 ## Contributing
 
 1. Make a copy of this repository