If you are going the URL hacking approach for reports, this blog does a good job of walking you through the steps.
Basically, you set up a report with predefined filters (using the
Add button) where the field name and operator are preset and the comparand value not relevant if you plan on overriding the value.
Contact ID equals anything
Stage equals anything
The first filter's comparand value is set by URLParam
pv0, the second comparand is URL param
pv1, and so on
Best practice is to put this report in some folder that is off limits to editing by anyone other than the sysad as if the filters are reordered or you change the field name, the URL hacking override will fail.
Note that the filters at the top of the report builder should be set to pull in all records that could ever be needed as overriding those params is beyond the scope of this answer (so, be sure to include a date filter that includes all records you would ever need and qualify the date range with a pvX parameter if you just need
Note that if overriding a
pvX comparand that can take on the value of a special date filter, use the SOQL syntax, not the user syntax. That is,
The usual caveats exist on URL hacking, these params are not SFDC-supported and could change. I would note that Conga's entire application leverages overriding
pvX to provide runtime customization of Conga Composer reports so they'd be pretty mad if SFDC made a change. And Conga is one of SFDC's leading appexchange partners.