Every limit, cap and sample size in one place
Every bound in MarqIQ, grouped by where you meet it, with what happens when you reach it and whether you are told. Where an analysis is capped, the sample is an even spread across your whole history rather than the most recent records, chosen by a stable hash so the same records are read on every visit. Not every capped read is spread, though. Some take one end of the period instead — the Email tab, the reads of your own captured form fills, the Data Quality Center and write provenance — and where a row below knows which end, it says so. For the rule about naming the population behind any one figure, read What number is a money figure resting on?
How a capped read behaves
Three rules hold wherever a capped read takes a sample. They do not describe every capped read in the product: the Email tab, the reads of your own captured form fills, the Data Quality Center and write provenance are ordered rather than spread, so they take one end of the period rather than a slice through all of it.
- The sample is even, not recent. One record in every few is taken across the whole store, because recent records have had the least time to buy or to be overwritten, and reading only those makes a score look worse and a funnel leakier than it is.
- The choice is stable. The sample is picked by a fixed hash of each record's id, so two looks at the same data give the same figures.
- You are told, in the header rather than a footnote. The line reads “Read 12,400 of 77,662 …: an even sample spread across the whole period. Shares are reliable; counts are the sample's.”
Sync and fields
| Limit | Value | What happens at it |
|---|---|---|
| HubSpot contact properties discovered per sync | 3,000 | Above that, the list is cut. Custom properties sync automatically up to it |
| Picklist options saved per field | 500 | The rest are not stored in the field catalog. Counts of options are kept in full |
| HubSpot properties read per batch call | 250 | The list is split into chunks and merged by record id, so no field is dropped — only the number of calls changes |
| HubSpot search page size, and its result ceiling | 200 a page, 10,000 results | HubSpot's own ceiling. The sync walks by watermark rather than paging past it |
| Raw vendor payloads kept | 30 days | Swept on about one sync run in twenty. Deleting them removes the need to re-pull, never the records themselves |
| Spreadsheet import rows parsed | 25,000 | The tail is dropped and the audit says so. A report that silently described the first 25,000 rows of a 60,000-row file would be a lie |
| Spreadsheet upload size | 15 MB | A larger file is refused before anything is parsed |
| Values sniffed per column on import | 200 | Used to work out what the column is. Every row is still imported |
Where a field ceiling does and does not apply
The 3,000 above is HubSpot's alone. Salesforce syncs every field its describe call returns, standard and custom alike, in chunks merged on the record id, so an object with 900 fields syncs all 900. Marketo Engage works the same way: MarqIQ asks the instance which fields it defines and keeps every one of them, splitting the names into groups that each keep a request URL under about 6,500 characters and merging the groups on the lead id. Your custom Marketo fields sync, and the field catalog labels them as custom. The named list of 24 lead fields — identity, company, location, source, status, score and the two timestamps — is the floor of that request rather than the whole of it, and it is all that syncs when Marketo does not answer the describe call, which is a connection to fix rather than a cap. The one real Marketo field limit sits on the incremental change feed: the list of fields it watches for changes is trimmed to fit the same URL budget, so on a very wide instance an edit to a field past that point produces no change record until a full re-read reaches that person. Where a field is missing on any tool, read A field is missing from MarqIQ rather than assuming a cap.
How far back deletions can be seen
These are the vendors' own evidence windows, not settings: Marketo Engage 14 days, Salesforce 14 days, HubSpot 80 days, Pipedrive 30 days, Zoho CRM 60 days, Pardot (MCAE) 30 days. A deletion lane that has not run inside its window has permanently missed what happened before it, and says so rather than resuming quietly.
Analyses
| Limit | Value | What happens at it |
|---|---|---|
| People read by Lead scoring and Funnel | 80,000 each | An even sample above that, stated in the header |
| Fills read by Form fills | 60,000, the most recent first | Above that the older fills are not read at all, and this page does not sample evenly. The Captured tile says “the most recent; older fills are not shown”, and the line above the tiles says the read was capped |
| Closed deals read by Forecast accuracy | 2,000 | An even sample of the closed deals in that tool, stated in the method note |
| Records read for field history | 600 people and 600 deals on HubSpot and Salesforce; 600 people and no deals on Marketo Engage; 60 people and 60 deals on Pipedrive, Zoho CRM and Microsoft Dynamics | Marketo Engage syncs people and not deals, so there is no deal history to read there. The 60 is because Pipedrive, Zoho CRM and Microsoft Dynamics give history one record at a time. The page states which sample it read |
| Fields tested for their purpose, per object | 30 | The fields carrying a promise are taken first, then picklist fields |
| Revenue targets a workspace can save | 60, one for each period and each rep | The form stops at 60 and says so. A second target for the same period and rep is not kept. Only someone who can edit workspace settings can save one |
| Reps listed in an answer about a target | 12, most attained first | The rest are counted in the line under them: “3 more reps are not shown.” |
| Reps listed in an answer about who is doing best | 12, most revenue won first | The rest are combined into one row, Other, with their own counts. A number in the question, such as “top 5 sales reps”, keeps that many |
| Records listed behind one finding | 200 | You can open each of them in your tool. The finding's own count is the full number, not 200 |
| Deals, contacts and accounts read for field intelligence | 20,000 deals, 6,000 contacts, 10,000 accounts | An even sample above that |
| Linked contacts read for touch paths | All of them | Read with the deals they are linked to, a page at a time |
| Fills read for the advisor's signals | 20,000, the most recent, from the last 365 days | The result is marked as capped when the cap was reached |
| Audit result held in memory | 5 minutes, per tool and per date range | After that the stored audit is read again. Recompute works it out anew |
| People read by one statement of the audit | 100,000 people | A larger store is read a part at a time and each part is kept. The page says “still being worked out” with how many have been read |
| Deals read by one page of the audit | 10,000 deals | Each page is kept; what changed since a page was read is read again before the figures are put together |
| Stored audits the hourly run looks at | 48 workspace-tools: 24 active, whoever has waited longest first, and 24 that sync every six hours | A workspace beyond that waits for its turn. Its audit stays on screen with the date it was computed |
| Unfinished audit work kept | 48 hours since the last part was added | After that the next attempt starts from the store as it is |
| Failed attempts before the page says so | 3 in a row | The line then says the attempts did not get through, when the next one is, and that Recompute tries now |
Floors: how few records is too few
| Floor | Value | What it governs |
|---|---|---|
| Records behind any rate | 30 | Below this a rate is shown with its counts and no verdict, anywhere in the product |
| Records behind a field's history | 20 | Below this the field is listed as understood but not tested |
| People delivered, for one email send to be judged | 100 | Below this the send reads Too few recipients to judge |
| Clicks in the period, before any send is judged | 30 | Below this MarqIQ falls back to opens, and below 30 opens judges nothing |
| Sends on each side of a subject-line comparison | 3 sends and 500 people delivered | Below either, the style is not called out |
| Deals behind a named owner | 5 | Below this no owner is named at all |
| People carrying both stage dates, before a timing is shown | 10 | Below this no median time is claimed for that step |
| Deals in the store, before the Executive Read appears | 5 | Below this the tab says so and names what it needs |
Cleanup and intelligence
| Limit | Value | What happens at it |
|---|---|---|
| Duplicate groups returned | 200, highest confidence first | The total is still reported, so you can see how many were found |
| Normalisation rules shown per field | 50 | The rule count and the number of records affected are given in full |
| Records enriched per request | 25 by default, 50 at most | A larger request is cut to 50 |
| Records written back per push | 500 | The push stops there and the rest are left untouched. Push again to carry on. A sync-back has the same ceiling of 500 records |
| Lowest-quality profiles listed | 50 | The quality figures themselves cover every profile |
Tracking and forms
| Limit | Value | What happens at it |
|---|---|---|
| HubSpot forms read in one hidden-field run | 1,000, in pages of 100 | Above that, the remaining forms are not touched in that run |
| Marketo Engage forms read in one run | 200 | Above that, the remaining forms are not touched in that run |
| Fills read when filling first touch from capture | 50,000, oldest first | The earliest capture for each address is the one used |
| Records one first-touch fill takes, on First-touch Backfill | 2,000 | The result says how many more are left for another run. Click Run workflow · N records again. Where the result lists refused records, fix what their reason names first |
| How long one first-touch fill writes, into HubSpot or Marketo | 54 seconds | Nothing new is sent in the last 4 seconds. The live read of each record before the write counts inside the same 54 seconds, 100 records a read in HubSpot and 300 in Marketo. A record the run had not read or sent is counted as not reached, and nothing was written to it. A record HubSpot refused in a batch, which the run had no time to send on its own, is counted as refused in a batch. A record in a request still out at the end is counted as not answered. The last line of the result says what to do next. A refused record is left out of the next runs for 7 days, so fix what its reason names first |
| Days a record the tool refused is left out of the first-touch fill | 7 | Only a refusal of the record’s own counts (a value the tool will not take, a record it no longer has), never the sign-in, the permission, a limit or a missing field. The record is tried again after 7 days, or as soon as a sync changes the values it would be sent, and its entry is cleared when it is written. The result and the page say how many are skipped and until when. MarqIQ remembers up to 4,000 such records a tool, the latest refusals; past that the oldest are tried again |
| Waits in a first-touch fill when Marketo says to slow down | 3 (1, 2 and 4 seconds), never past the 54 | Marketo allows 100 calls in 20 seconds and ten at a time. A request it refuses for either limit is sent again after the wait, and counted as refused only after the third. Its daily quota does not clear by waiting: the run stops sending and the reason says when the quota resets |
| Reasons listed when a tool refuses records in a first-touch fill | 5, the most common first | Where there is more than one reason, each gives how many records it was given for, and the result says how many more reasons there were. What HubSpot said of a batch it refused is listed the same way, five sentences at most, with no count |
Change sets
| Limit | Value | What happens at it |
|---|---|---|
| Items in one run | 500 | The run is cut at a whole-record boundary, never halfway through a person, and the summary says how far the proposal read. Propose again once this run is applied |
| Contacts read to build one proposal | 100,000, in pages of 2,000 | The read goes in order and stops when the set holds 500 changes or at 100,000 contacts, whichever comes first, and the summary says which: Read all 330 contacts or Read the first 40,000 of 3,000,000 contacts; 500 are in this change set. A proposal stopped at 100,000 leaves its place, and the next proposal of that operation carries on from there; at the end of the list the next one starts again from the first. Captured form fills are read for each page’s addresses only |
| How long a proposal stands | 14 days | After that it expires and has to be proposed again, so nobody applies a plan built on a month-old reading |
| How long an applied change can be undone | 30 days | After that the undo is no longer offered |
| Open change sets in a workspace | 20 | The 21st is refused: 20 change sets are already open in this workspace, the most that can be open at once. Approve, apply or reject some first. The same limit meets an AI assistant’s token |
| Open changes to one field of one record | One | A field of a record that an open set already lists, whichever operation proposed it, is left out of a new proposal, so two sets can wait at once and no record is proposed twice |
| Proposals in a minute | 20 a workspace | The 21st is refused: This workspace has proposed 20 change sets in the last minute. A proposal counts the moment it is saved, whatever becomes of it; a refused one does not |
| How long one apply or undo keeps starting work | 150 seconds | Everything written by then is recorded, and the items it did not reach are counted as not attempted. Propose again after an apply; click Put everything back again after an undo |
| Requests for one batch of a change set | Three: a read, a write and a second read. HubSpot takes 100 people a batch, Marketo 300 | A HubSpot batch refused because of a record in it is halved and each half sent again until the refused part is 13 people or fewer; those go one at a time, five at once. That is about 20 requests for one bad record in 100. A Marketo request refused that way is sent again one person at a time, five at once and no faster than about four a second |
| Calls to HubSpot for one connection, from a change set | 80 in any 10 seconds | HubSpot allows its smallest accounts 100. Past 80, the next call waits until the oldest is 10 seconds old |
AI answer visibility
| Limit | Value | What happens at it |
|---|---|---|
| Tracked prompts held | 200 | A workspace already above it keeps its prompts and cannot add more |
| Active prompts one run may ask on MarqIQ's included engines | 20 | The run is refused before anything is counted, saying how many it would ask and what to do. It is never cut down to a sample |
| Active prompts one run may ask on your own AI keys | Every tracked prompt, up to the 200 above | No fair-use budget applies at all on your own keys |
| Competitors tracked | 8 | Above that, a new one has to replace an existing one |
| Citations kept per answer | 50 | The rest are not stored |
| A run counted as current | 30 days | Older than that, it is marked stale rather than quoted as today's position |
On MarqIQ's included AI engines, each workspace also has an hourly and a daily budget per action. None of these applies when the request runs wholly on your own AI keys.
| Action | Per workspace, per hour | Per workspace, per day |
|---|---|---|
| Visibility checks | 6 | 16 |
| Prompt drafts | 10 | 20 |
| Recommendation drafts | 10 | 20 |
| Brief drafts | 30 | 40 |
| Brand profile analyses | 10 | 20 |
A refusal says which limit was hit, when to retry, and that connecting your own AI accounts removes it.
Note
A run is counted once, when it starts, and never again as it continues. A run that takes several requests to ask every prompt therefore spends one visibility check, not one per request.
Plan limits
| Plan | People | Tools connected | Tracked form fills |
|---|---|---|---|
| Free Trial | 5 | 2, one per category | 10,000 |
| Starter | 3 | 1 | 10,000 |
| Pro | 5 | 2, one per category | 100,000 |
| Business | 10 | 4, any categories | 500,000 |
| Enterprise, Partner | Agreed with you | Agreed with you | Agreed with you |
Business is capped rather than unlimited, and stated as such: each workspace has a database of its own, and one heavy workspace on an open plan costs more than the plan earns.
Extra seats can be bought on Starter, Pro and Business, at most 50 of them in one order. A workspace that needs more than that is an Enterprise conversation; Enterprise and Partner seat counts are agreed during scoping.
Take care
Where a limit is reached, MarqIQ says so on the screen that reached it. This page collects the bounds on the analyses named here; it is not a promise that nothing else in the product is bounded. So if a figure looks low and no note on the screen explains it, report it rather than assuming a cap you cannot see — an unexplained figure is the thing worth chasing either way.
Next steps
Related articles
Was this article helpful?