The following is Part IV in a multi-part series on how to draft and leverage an ESI protocol in any litigation. Part I of our series discussed the When, How and Why in planning for and creating your ESI protocol. Part II addressed the Key Components of an ESI Protocol, and Part III walked through the Top 10 Situations You Can Avoid with a Protocol.
In conjunction with this series, eDiscovery Assistant has created a new section in Checklists and Forms titled ESI Protocols that will include new content with each part of this series. That section includes sample ESI protocols, checklists on what to include and a list of metadata fields for inclusion in your protocol.
Drafting an ESI protocol that meets the needs of your case means identifying each type of data that is likely to be produced in a case and including the parameters for that data type in the protocol. Lately, we’ve seen a big issue with parties failing to provide specifications in protocols for a key type of data that’s showing up regularly: Social Media. If you are an employment lawyer, dealing with marketing issues in commercial litigation, or working on trademark infringement or other IP claims, social media evidence is key. But we see it as well in family matters, class actions, and any place where the online presence of a company OR an individual may be important evidence in a case.
So, how do you plan for social media evidence in an ESI protocol? Consistent with other data types, your protocol needs to include language to deal with the big 3 — the image, text (if it exists) and metadata. But social media adds another wrinkle and that is the information about a social media post — think likes, comments, and other means to react to a post that differ by platform. Will those reactions be included in what you capture? Are they necessary for the case? That will vary case by case, and you need to consider it during collection and what you want to include in your protocol.
First, a bit of terminology. An individual entry on social media — namely a post on Facebook or Instagram, a tweet on Twitter — is called a post/tweet/etc. Contrast that with a user’s entire profile that contains all of the posts, tweets, etc. You need to understand whether you need/want individual posts or the full profile.
Here’s a list of several steps you need to work through to include the appropriate language in your ESI protocol to ensure you get the data you need about social media:
- Identify the list of social media platforms or posts you want. To do this step, you can’t just guess, you’ll have to get on the computer and start looking for what social platforms contain data you want produced in discovery. Each platform has its own unique features and metadata that have to be considered — what you need from Tik Tok is not the same as what you need from Twitter, Reddit, Instagram or Facebook. Note that we are talking strictly social media here, we’ll cover instant messaging (including WhatsApp, iMessage and others) in another post. What platforms is your client on that need to be preserved? What platforms is the opposing party on that you want to have preserved/produced? Make a list of what you need, the date ranges covered or the subset of posts and the metadata that you want from each platform. More about metadata two steps down, but you want to start thinking about it when you identify the platforms.
- Identify the scope of data you want from each platform. Make a list of the date range(s) covered by the case or the subset of posts (i.e. a topic or set of topics that are covered) that are relevant. Spend time on each platform that is publicly available to really drill down and know whether you can create a list of URL’s by post using a topic or key words that you can search for, or if the posts are so voluminous that you want to preserve the entire profile. YouTube videos are one offs, you’re unlikely to collect the whole channel. But a Facebook profile dedicated to a brand may be entirely relevant over a specific date range. Be thoughtful for each platform and get on and see how the parameters you ask for will affect the scope of the data you get. Couple that with the bullet below on how you want to show evidence at trial. All of these work together.
- Identify the metadata you want for each platform. Each platform has different fields of metadata and you need to identify them for each. Some sample metadata fields include URL for the post itself (helpful for Twitter, YouTube, Facebook and others), the Title of the post (useful for Twitter, not as much for other platforms), the SMA Account (Social Media Account) that identifies the author of the post. For each field of metadata you request, make sure the other side can provide it, and make sure you code your review platform with those fields to populate when the data is loaded from production. Think of which metadata fields by how you will want to sort the data — do you want to sort by date? By keyword? By author of the post? That tells you which metadata fields you need to have. Many of the standard metadata fields you use in an ESI protocol will also provide data on the social media posts including Date, Custodian, RecordType (be sure to specify this will be social media), TimeSent, etc. Each of the recommended metadata fields for documents and social media are included in the List of Metadata Fields in the ESI Protocol section of the Checklists and Forms on eDiscovery Assistant.
- Consider how you will want to show posts or profiles to the judge or jury at trial and then request image files. Often, we ask for the preservation of entire profiles for social media, but we often want to either have individual posts as exhibits, or we want to create a montage of posts that show the behavior at issue for trial. Think carefully about what you will want to show and the context you want it in when drafting your protocol. Often, we ask for specific posts individually with all metadata and then a full profile to show context of the individual posts.
- Review the posts when they are collected or produced to make sure your images and comments appear the way they do on the sites so jury’s will recognize the content. QC (or quality control) upon collection or production is key here. Don’t just load data and forget about it, you need to make sure you have what you need, that the images are the correct size, they are of sufficient quality to view them and be blown up as exhibits. Verify that you have all the metadata fields for each post, test the URL to make sure it links properly and verify the image looks good. You’ll be in a world of hurt if you don’t have an image at the time you have to compile trial exhibits and the post no longer exists.
- Forget about using the Facebook download of a user profile. Facebook created a setting that allows a Facebook user to download their profile, but the download separates all of the file types so that the data appears nothing like it looks on Facebook. You’ll have files of images, text, and links, but none of it will be related, and comments, likes and other data isn’t captured in that download. And it’s almost all in HTML, which isn’t read by most ediscovery platforms. In short, it’s rarely a good preservation or collection tactic.
Adding another layer of complication, around the time of the 2020 Presidential election, social media platforms altered their API’s to prevent election interference. That had the added issue of complicating collection of social media by current tools like X1 and Page Vault. Do tests when collecting, and make sure you can provide the metadata you are both asking for the other side to provide, and that it’s available. Work through these issues BEFORE you agree to a protocol and you’ll have a much easier time using your social media data when it comes to trial.
Social media is crucial evidence, and to get all of it that allows you to filter, sort and present it, you need to plan for it in your ESI protocol. Do the work up front to reap the benefits at trial.
In Part V of this series, we cover manner of production. Manner of production is an aspect of your ESI protocol that directly impacts how fast you’ll be able to get data loaded when you receive it.
