中繼資料與合規：導致數碼素材遭拒的常見錯誤

Last March I lost a full weekend to a CSV header. I had 60 vector files ready for Adobe Stock, a batch-generated metadata file, and I hit submit feeling good about it. Every single row came back rejected in under a minute. The reason was not the art. The reason was that my CSV had six columns instead of five, and Adobe's ingest checks the header row before it looks at anything else. Sixty assets, zero uploaded, one lesson learned the hard way.

That failure is why metadata and compliance are the first thing I check now, before I generate a single new file. Here is what actually works.

The header row is a gate, not a suggestion

All three major channels I submit to reject a malformed CSV instantly. Adobe expects a 5-column layout. Vecteezy expects 4 columns. Dreamstime wants 15. If your header does not match exactly, the file never gets ingested and you get a generic error that does not tell you which column is wrong.

The mistake I made was building my metadata by hand in a spreadsheet, once, and then reusing that sheet for every platform. Each platform wants a different shape. Hand-editing between them is how a stray extra column sneaks in. The fix was boring: one script that reads a folder of files and writes the exact header each platform demands, and nothing else. make_metadata.py in my pipeline does this with only the Python standard library, no packages to install. I run it three times with a --platform flag and get three correct CSVs from the same folder.

Filenames are not titles

The second rejection reason I hit, this time on Vecteezy, was lazy titles. When I did not supply real titles, my script fell back to the filename, title-cased. So a file named floral_frame_04.jpg became "Floral Frame 04". Reviewers see that as low-effort metadata, and low-effort metadata correlates with rejection in my experience. It also kills search discovery, which is the whole point of metadata in the first place.

What works: a JSON file of real titles and keywords per asset, passed in explicitly. It takes ten minutes for a batch of 40 and it is the difference between "fine for a first pass" and "ready to submit". I keep the fallback in the script because a first pass is useful, but I treat filename-derived titles as a placeholder, never a final state. If you automate this pipeline, build the placeholder step in deliberately so you can see which assets still need real metadata before submit.

Double-posting gets you flagged faster than bad art

This one scared me straight. Early on I re-ran an upload batch after a partial failure, forgot which items had actually gone through, and double-posted about a dozen assets. Duplicate submissions are one of the fastest ways to get an account flagged. The platforms do not care that it was an accident.

The fix is a plain-text ledger. upload_tracker.py is about as simple as a script can be: pending shows what is not done, done marks an item, status gives the overview. It uses the standard library alone. The rule I follow now is that the ledger is the source of truth, not my memory and not the platform dashboard. Any batch job checks the ledger before it acts, and a re-run can never post the same file twice. This costs me nothing and has prevented every repeat of that mistake.

AI-generated content has its own compliance layer

If any part of your asset came from an AI image generator, the platforms require you to declare it. Adobe has a specific checkbox for generative AI content, and submitting AI work without the declaration is a policy violation, not a style choice. Beyond the declaration, the art itself has to pass review: no garbled text, no mangled hands, no recognizable trademarks or people. My rejection rate on raw AI output was high enough that I started inspecting every file at low resolution before submit, which also fits my server budget. Reviewing a preview at 60 dpi instead of rendering at 300 keeps the check fast on a box with 1 vCPU and 2 GB of RAM.

Budget note, since it matters for solo makers: AI image generation is not free at volume, and it is often the largest line item in the pipeline. Everything else I run costs zero, on a free stack, on hardware that would otherwise sit idle. Plan your generation batches so you are not paying twice for assets that get rejected over metadata you could have fixed first.

Package and document before you submit, not after

The last compliance-adjacent habit: keep a fixed folder structure. Mine is assets/ for raw output, output/ for ready-to-submit files with their metadata CSV, packs/ for finished product zips with covers, and research/ for notes. I once deleted my research folder to "clean up" and immediately regretted it, because those notes were the raw material for the next three products. Keep it forever.

On the small server, one process at a time, gc.collect() between assets, and measuring peak RSS with ru_maxrss instead of guessing. That pipeline packaged 39 products, about 856 MB of output, on 1 vCPU and 2 GB of RAM with no GPU. None of it is clever. All of it is habits that prevent rejections and crashes.

Where this lives now

Everything above is baked into the Pipeline Starter Kit: the four scripts that wrote the correct Adobe 5-column, Vecteezy 4-column, and Dreamstime 15-column CSVs, tracked uploads so nothing double-posted, and packaged the products. They ran on the same tiny server, validated across roughly 19,000 lines of pipeline code and 300+ pages of research behind the rules. If you want the tools instead of the lessons, they are here.

Get compliance metadata kit

Building digital products? Free guides & kits for digital product sellers.